Можно ли вручную удалить индексы в материализованном представлении перед полным обновлением (Oracle 11g)?

У меня есть материализованное представление с 12 миллионами записей. Каждый раз, когда выполняется полное обновление, для atomic_refresh установлено значение false. При обновлении ведение журнала не включено, и mview является локальной копией удаленной таблицы. Никаких стыковок нет. Для обновления mview требуется около часа, и я хочу уменьшить время обновления.

Существует около 20 индексов, и я думаю, поскольку это полное обновление без atomin, удаление и восстановление индексов занимает много времени. Могу ли я вручную удалить индекс перед обновлением и построить его вручную после завершения обновления?


refresh materialized-views oracle11g
person anesh    schedule 26.02.2014    source источник
comment
Не могли бы вы? Конечно. Есть ли у вас основания полагать, что это действительно улучшит производительность? Если вы копируете по сети 12 миллионов строк каждый раз, когда выполняете обновление, я бы ожидал, что пропускная способность сети будет, безусловно, узким местом. Есть ли у вас какие-то основания полагать, что обслуживание индексов на самом деле является узким местом? Можете ли вы выполнить инкрементное (быстрое) обновление вместо полного обновления?   -  person Justin Cave    schedule 27.02.2014
comment
У меня есть другие mviews с таким же объемом данных и меньшим количеством обновлений индексов в разумные сроки. Вот почему я думаю, что проблема заключается в поддержании индекса.   -  person anesh    schedule 27.02.2014

Ответы (1)


arrow_upward
0
arrow_downward

Не могли бы вы? Конечно.

Это самый эффективный способ настроить ваш процесс? Возможно нет. Выполнение инкрементного обновления, а не полного обновления, позволит вам перемещать только те данные, которые фактически изменились по ссылке базы данных, и, вероятно, значительно снизит стоимость обслуживания индекса. Кроме того, если вы выполняете неатомарное обновление, это означает, что Oracle выполняет прямую загрузку в фоновом режиме. Это означает, что обслуживание индекса уже откладывается до тех пор, пока данные не будут загружены в таблицу, что ограничивает потенциальную выгоду от удаления и воссоздания индексов.

Если вы решите вручную отбрасывать и заново создавать индексы каждый раз, вам нужно будет следить за тем, чтобы они постоянно обновлялись при добавлении или удалении новых индексов. Это проблема обслуживания, которую относительно легко упустить, когда какой-то разработчик просто хочет добавить или удалить индекс.

person Justin Cave    schedule 26.02.2014
comment
Я согласен с тем, что постепенное обновление - эффективный способ. Но если я сделаю инкрементное обновление, это создаст накладные расходы на ведение журнала при внесении изменений в главную таблицу. И регистрация фактически нигде в базе данных не включена. - person anesh; 27.02.2014
comment
@anesh - Да, вам понадобится материализованный журнал просмотра исходной таблицы, чтобы отслеживать изменения. Это повлечет за собой некоторые накладные расходы на INSERT операции с источником. Но это значительно снизит накладные расходы на чтение каждого блока из исходной таблицы каждый раз, когда вы выполняете обновление. - person Justin Cave; 27.02.2014