При выполнении массовой загрузки данных из хранилища данных в таблицу, для которой мне не требуется ведение журнала, обычно мой процесс заключается в следующем:
Это работает нормально, но удаление и повторное создание индексов может вызвать проблемы, поэтому мне было интересно, считают ли люди этот шаг необходимым. Я понял, что начиная с 10g и позже, такое создание индексов было оптимизировано, так что индексы были перестроены после самой загрузки данных.
У кого-нибудь есть опыт в этом?
вы говорите, что удаление и повторное создание индексов может создать проблемы. Другой способ сделать это - пометить индексы как непригодные для использования и затем восстановить их. Таким образом, их определение (имя, столбцы, табличное пространство и т. Д.) Никогда не «теряется», даже если какой-то шаг не удался.
Итак, на шаге 2 переберите все индексы таблицы и выполните:
ALTER INDEX my_index_name НЕИСПОЛЬЗУЕТСЯ;
и на шаге 4 перебираем индексы и перестраиваем. Вы можете указать отсутствие логирования, желаемый уровень параллелизма, сжатие индекса и т. Д .:
ALTER INDEX my_index_name REBUILD NOLOGGING PARALLEL 16;
Более эффективно строить индексы за один раз, чем «построчно». В первом случае Oracle выполняет одно полное сканирование таблицы, сортирует и записывает индекс. Если индекс поддерживается во время массовой загрузки, он постоянно обновляется во время загрузки, поэтому ему необходимо постоянно обновлять свой листовой блок повсюду, выполняя больше работы и операций ввода-вывода. Зачем? потому что каждый индексный блок будет обновляться несколько раз в разные моменты времени загрузки.
Кстати - надеюсь, у вас есть «шаг 5» - собирать статистику по таблице и индексам (параллельно)
Мы делаем почти то же самое, за исключением того, что выполняем массовую загрузку во временные промежуточные таблицы, а затем переносим их в фактическую таблицу. Я думаю, что создание индексов после загрузки данных - вполне нормальный шаг ETL и не должен вызывать никаких проблем. Это занимает какое-то время, но без индексов все идет намного медленнее. Мы никогда не сталкивались с проблемами создания индексов для уже заполненных таблиц.