Проблема: Значительное снижение производительности при полном обновлении sh, когда индексы активны. Я не совсем уверен, почему наличие активных индексов во время полного обновления sh может привести к значительному различию в производительности. В настоящее время у нашего хранилища данных есть проблема с избыточной индексацией, но я был удивлен, увидев огромное снижение производительности даже с одним активным индексом по сравнению с отсутствием активного индекса при полном обновлении sh.
Oracle Версия 12 c
Исследование: Материализованное представление refre sh Ужасное снижение производительности Я нашел это на SO, но это не так Не обязательно отвечать на мой вопрос, почему индексы могут привести к снижению производительности. Я могу продолжить с предложением отбросить индексы и перестроить после завершения refre sh, но я все еще пытаюсь выяснить ПОЧЕМУ.
Пример теста производительности: У меня много MV , но это пример того, как я тестировал MV и связанные с этим расходы. Я протестировал около 10 MV, и все они показывают ту же схему. Обратите внимание, что я изменил код для удаления всех имен объектов
Со всеми активными индексами:
exec dbms_mview.refresh('MY_MV_TEST','C');
Exe c реального времени, как сообщается из SQL Разработчик: ~ 153 с
Получение производительности:
SELECT elapsed_time, log_purge_time
FROM dba_mvref_stats
....
elapsed_time = 151 log_purge_time = 1
ALTER INDEX IX_MY_MV_TEST_1 UNUSABLE;
....
ALTER INDEX IX_MY_MV_TEST_13 UNUSABLE;
Повторный запуск refre sh:
exec dbms_mview.refresh('MY_MV_TEST','C');
Получить статистику от dba_mvref_stats:
elapsed_time = 27 log_purge_time = 1
Это было немного удивительно, поэтому я попробовал 1 на 1, с одновременно активен только 1 индекс. Для каждого индекса сообщалось, что elapsed_time равняется 33, а log_purge_time равняется 2 (я думал, что это было немного странно, они все тоже сообщали в одно и то же время). Есть несколько других MV, которые go от 300 до 40 с. До сих пор я проводил тестирование только на небольшом подмножестве нашего хранилища данных, и я предполагаю, что некоторые из наших более крупных MV покажут те же результаты. Перестройка индексов занимает всего 11 с, как сообщает SQL разработчик.
MV DDL: Переименование всех объектов займет некоторое время, но при необходимости я сделаю это, если потребуется. На данный момент это общий вид этого конкретного определения MV. В предложении SELECT есть только столбцы, пара операторов case и пара substr () и cast ().
CREATE MATERIALIZED VIEW MY_MV_TEST
BUILD DEFERRED
USING INDEX REFRESH FORCE ON DEMAND
USING DEFAULT LOCAL ROLLBACK SEGMENT
USING ENFORCED CONSTRAINTS AS
SELECT column1, column2, CASE..., SUBSTR(..), CAST()...
FROM mv1, mv2, mv3
WHERE mv1.column1 = mv2.column1
AND mv1.column1 = mv3.column1
AND ... (other simple conditions using the equality operator)
Также обратите внимание, что все проверенные мной MV - это REFRE SH БЫСТРО способен. DBMS_MVIEW.EXPLAIN_MVIEW показывает, что они поддерживают REFRE SH FAST. Я использую ПОЛНЫЙ REFRE SH только для тестирования.