Oracle - Materialized View изменяет структуру настолько медленно

У меня есть огромное материализованное представление, которое я должен скорректировать. Это простая настройка, так как я просто добавляю функцию NVL в оператор select.

т.е. Оригинал...

Select this,
       that.....

т.е. Изменено

Select NVL(this, orThat) as this,
       NVL(That, orThis) as that

Выполнение запроса занимает 26 секунд, но из-за количества извлеченных строк (2,3 миллиона) он очень медленный. Он работал почти 5 дней подряд, а затем я остановил его.

Это проблема, тем более, что мне нужно доставить это клиенту, а он не может запустить скрипт 5+ дней для создания MV.

Вопрос: Есть ли способ ускорить изменение/воссоздание MV? Было бы быстрее, если бы я изменил MV, или это было бы примерно так же, как удаление и воссоздание?

Версия Oracle = 10g


oracle materialized-views oracle10g
person contactmatt    schedule 18.05.2011    source источник
comment
вам нужно будет проверить это, но есть вероятность, что воссоздание будет быстрее (вы касаетесь всех строк, это чертовски сложно).   -  person Mat    schedule 18.05.2011
comment
выполнение запроса занимает 26 секунд... вы имеете в виду, что он НАЧИНАЕТ возвращать строки через 26 секунд. Попробуйте выполнить этот запрос, используя /*+ ALL_ROWS */ подсказку   -  person tbone    schedule 18.05.2011

Ответы (2)


arrow_upward
9
arrow_downward

Вы не можете изменить определение запроса для материализованного представления — его нужно удалить и создать заново. Тем не менее, вы можете попробовать этот подход, это может быть быстрее, чем воссоздание всего MV:

  1. Отбросьте материализованное представление, используя PRESERVE TABLE.
  2. Обновите данные в таблице, которая раньше была MV, чтобы отразить новые определения столбцов.
  3. Воссоздайте материализованное представление, используя предложение ON PREBUILT TABLE.

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

person DCookie    schedule 18.05.2011
comment
Это звучит как хорошая идея, я попробую и сообщу вам результаты - person contactmatt; 19.05.2011

arrow_upward
1
arrow_downward

5+ дней, чтобы построить MV из 2-3 миллионов строк? Это waaaaay не в порядке, слишком много, чтобы быть просто плохим SQL. Я предполагаю, что вы можете быть заблокированы каким-то другим процессом (?). Не уверен, но проверьте это в другом сеансе после запуска перестроения MV:

select s1.username || '@' || s1.machine
  || ' ( SID=' || s1.sid || ' )  is blocking '
  || s2.username || '@' || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
  from v$lock l1, v$session s1, v$lock l2, v$session s2
  where s1.sid=l1.sid and s2.sid=l2.sid
  and l1.BLOCK=1 and l2.request > 0
  and l1.id1 = l2.id1
  and l2.id2 = l2.id2 ;

Просто предположение. Если вы используете Toad, вы также можете получить эту информацию (через Database->monitor->session browser). Это также покажет вам прогресс Long Ops (сканирование таблиц и т. д.).

Редактировать: О, кстати, создайте MV, используя nologging, это должно немного помочь в целом, как только вы определите, что у вас нет проблем, указанных выше.

person tbone    schedule 18.05.2011
comment
Если вы делаете полное обновление, оно сделает truncate...insert/*+append*/. Если указано отсутствие ведения журнала, он может обойти повторную генерацию для таблицы (но все равно будет генерировать некоторые для индексов). Это значительно уменьшит (но не устранит) количество повторов, и вы должны увидеть прирост производительности (при полной перестройке). - person tbone; 26.05.2011