Вывод: IOT-таблицы неоходимо проектировать и заполнять так, чтобы обращения к сегменту OVERFLOW происходили редко. Если мы выносим в сегмент OVERFLOW поля, к которым обращаемся всегда или часто, то при большом объёме данных скорость её чтения по мере заполнения будет падать лавинообразно. В таком случае IOT-таблица вырождается в обычную HEAP и её лучше было бы с самого начала создавать как HEAP.
Вот как это обнаружил...
Как известно, для B-tree индексов одним из параметров, которые определяются на сборе статистики, является фактор кластеризации (clustering factor). Этот числовой параметр показывает, сколько раз приходилось читать другой блок таблицы при переходе к следующему значению индекса.
Так вот, этот параметр оказался ненулевым для некоторых IOT-таблиц. Это стало для меня сюрпризом. Об этом не написано в документации.
Потребовалось некоторое время, чтобы сообразить, что имеется ввиду кластеризация сегмента OVERFLOW по отношению к основному сегменту IOT-таблиц.
Этот имеет практическое применение. Для больших таблиц время полного просмотра (с извлечением полей, которые находятся в OVERFLOW) и время сбора статистики будет расти лавинообразно и может стать неприемлемым -- сессия "зависнет" (так это и было обнаружено).
Большой таблицей здесь можно считать такую, которая не помещается полностью в буферный кэш.
Это связано с тем, что при переходе к следующему значению индекса в IOT сервер вынужден снова и снова читать блоки OVERFLOW, которые уже читал ранее. Пока блоки есть в кэше -- все нормально, но при достижении некоторого порога -- начнётся лавина.
На тестовом экземпляре при увеличении количества строк в 4 раза время сбора статисики увеличилось с 70 секунд до 2222 секунд (в 31 раз). Полный просмотр даёт тот-же результат
Как такие таблицы найти ?
select * from ALL_INDEXES
where INDEX_TYPE = 'IOT - TOP' and CLUSTERING_FACTOR > 0
Небольшое значение CF приемлемо.
Также, необходимо поискать в DBA_SEGMENTS размеры сегментов -- основного и OVERFLOW.
Как исправить ?
Фактор кластеризации и сама таблица и её OVERFLOW улучшаются (реорганизуются) если выполнить
alter table <iot_table_name> move
alter table <iot_table_name> move overflow
При этом IOT–таблицу НЕ придётся переиндексировать, поскольку B–tree индексы IOT–таблиц строятся на логических rowid, которые не изменяются при MOVE, в отличие от физических.
После подобной операции MOVE время сбора статистики и полных просмотров IOT–таблицы сокращается (возможно, очень существенно, в 5 раз, но зависит от данных).
Вот как это обнаружил...
Как известно, для B-tree индексов одним из параметров, которые определяются на сборе статистики, является фактор кластеризации (clustering factor). Этот числовой параметр показывает, сколько раз приходилось читать другой блок таблицы при переходе к следующему значению индекса.
Так вот, этот параметр оказался ненулевым для некоторых IOT-таблиц. Это стало для меня сюрпризом. Об этом не написано в документации.
Потребовалось некоторое время, чтобы сообразить, что имеется ввиду кластеризация сегмента OVERFLOW по отношению к основному сегменту IOT-таблиц.
Этот имеет практическое применение. Для больших таблиц время полного просмотра (с извлечением полей, которые находятся в OVERFLOW) и время сбора статистики будет расти лавинообразно и может стать неприемлемым -- сессия "зависнет" (так это и было обнаружено).
Большой таблицей здесь можно считать такую, которая не помещается полностью в буферный кэш.
Это связано с тем, что при переходе к следующему значению индекса в IOT сервер вынужден снова и снова читать блоки OVERFLOW, которые уже читал ранее. Пока блоки есть в кэше -- все нормально, но при достижении некоторого порога -- начнётся лавина.
На тестовом экземпляре при увеличении количества строк в 4 раза время сбора статисики увеличилось с 70 секунд до 2222 секунд (в 31 раз). Полный просмотр даёт тот-же результат
Как такие таблицы найти ?
select * from ALL_INDEXES
where INDEX_TYPE = 'IOT - TOP' and CLUSTERING_FACTOR > 0
Небольшое значение CF приемлемо.
Также, необходимо поискать в DBA_SEGMENTS размеры сегментов -- основного и OVERFLOW.
Как исправить ?
Фактор кластеризации и сама таблица и её OVERFLOW улучшаются (реорганизуются) если выполнить
alter table <iot_table_name> move
alter table <iot_table_name> move overflow
При этом IOT–таблицу НЕ придётся переиндексировать, поскольку B–tree индексы IOT–таблиц строятся на логических rowid, которые не изменяются при MOVE, в отличие от физических.
После подобной операции MOVE время сбора статистики и полных просмотров IOT–таблицы сокращается (возможно, очень существенно, в 5 раз, но зависит от данных).
