Евгений ФадеевТеперь складывается на CREATE UNIQUE CLUSTER INDEX... Я так понимаю выход только в увеличении размера/количества журнальных файлов?
А зачем именно кластерный индекс ? Он сильно увеличивает объем работы (по переупорядочиванию всей таблицы) и ,соответственно, объем логов...
И в чем проблема увеличит все таки логи ? Мне кажется, что у вас их совсем немного.
Строили индексы на 90млн. таблице и хватало логов на гиг (если не ошибаюсь)

Евгений Фадеев Журавлев Денис Евгений Фадеев Журавлев ДенисCLUSTER -- я бы никогда этим не пользовался, абсолютно не нужно.Ну, здесь можно поспорить...Пользы от IOT -- мало, в случае с информиксом еще меньше.А можно чуть подробнее?
У меня вполне стандартная ситуация: таблица-очередь. Выборки (и вообще вся работа) идут по ключу. Монотонно вверх. С моей точки зрения - выгода от кластерного индекса вполне очевидная.

Насчет АБСОЛЮТНОЙ безполезности я бы тоже поспорил :)
но соглашусь, что используют это крайне редко. Кстати, это один из способов заставить физически перезаписаться всю таблицу (устранение избыточной фрагментации, убрать множество версий после alter table и т.п.).
Вот как описывается кластерный индекс в литературе:
--------------
Кластерные индексы
Информация, хранящаяся в базе данных извлекается с жесткого диска блоками (секциями дискового пространства). С помощью кластеризации можно заставить данные размещаться на диске в порядке, предписанном индексом. Это может повысить эффективность извлечения данных, потому что оно будет происходить в порядке, близком к тому, в котором они извлекаются по индексу.
В нашем примере, если кластерный индекс построен по полю lname, строки с данными будут физически упорядочены по полю lname. Оператор SELECT, извлекающий большое количество записей из таблицы customer, в порядке сортировки поля lname будет работать более эффективно, особенно, если таблица большая.
Кластерный индекс изменяет физическое расположение данных на диске. Поэтому в таблице может существовать только один кластерный индекс. Кластеризация не поддерживается (не обновляется) при добавлении данных в таблицу или обновлении существующих данных. Поэтому кластерные индексы наиболее эффективны при использовании в часто используемых для чтения статических таблицах и менее эффективны в таблицах динамических.
Хотя кластерность и не изменяется при добавлении или обновлении данных в таблице, кластерный индекс может быть рекластеризован с помощью оператора:
ALTER INDEX имя_индекса TO CLUSTER
Для поддержания эффективности кластерного индекса, имеет смысл часто обновлять кластерный индекс, построенный по нестатической таблице.
Во время выполнения оператора ALTER INDEX TO CLUSTER сервер создаст на диске копию всей таблицы в индексном порядке перед удалением старой таблицы. Необходимо обеспечить достаточное количество дискового пространства перед проведением этой операции.
--------------

Журавлев ДенисВ случае информикса они (переход в таблицу по rowid) ВСЕГДА делаются.
Денис, не гони :)
Не всегда. Вспомни про "Key only"... Используется достаточно часто
Журавлев ДенисДа, это все про деатачид индексы.
А какая разница ? С присоединенніми индексами ситуация еще проще, т.к. страницы лежат вместе в одном экстенте.

Журавлев Денис sysmasterИ всем же я ошибся?Командой onparams логи любого размера можно добавить после инициализации, т.е. LOGFILES*LOGSIZE<>размер всего журнала.
Просить надо onstat -l
Или выполнить простой оператор:

Журавлев Денис vasilisНе всегда. Вспомни про "Key only"... Используется достаточно частоЯ помню. Просто это другой случай, к IOT отношения имеющий мало.
Я и не сомневался, что ты знаешь.
Но я среагировал на твое "ВСЕГДА" и мое замечание было больше для других читателей конференции, которые могли подумать буквально, что "В случае информикса они (переход в таблицу по rowid) ВСЕГДА делаются", что было бы неверно.