Производительность удаленных материализованных представлений в Oracle

У меня вопрос по поводу материализованных представлений Oracle ...

У нас есть две базы данных:

  1. Базовая база данных
  2. База данных отчетов

В базе данных отчетности есть:

  • ссылка базы данных на базу данных Core
  • ряд синонимов таблиц в базе данных Core
  • ряд Материализованных представлений, определенных поверх этих синонимов.

Представления настроены на ежечасное обновление.

С увеличением объема данных в исходной системе мы наблюдаем увеличение ЦП для материализации представлений.

При более внимательном рассмотрении выясняется, что процесс обновления представления создает набор результатов в базе данных отчетов и отправляет отдельные, меньшие по размеру операторы SQL в базу данных Core.

Некоторые из этих материализованных представлений очень сложны и содержат множество соединений между таблицами. Это приводит к миллионам маленьких SQL-операторов для базы данных Core.

У меня вопрос: не лучше ли создать соответствующее «сложное» представление в базе данных Core и иметь материализованное представление в базе данных отчетов в виде простого «SELECT * FROM CORE.MY_MAT_VIEW»

спасибо за любые указатели,

ура, Эван


sql performance oracle materialized-views
person Evan    schedule 16.07.2009    source источник
comment
Можно ли с уверенностью предположить, что когда вы говорите сложный, вы используете его так же, как Oracle, когда он говорит о сложных материализованных представлениях, то есть материализованных представлениях, которые не могут обновляться постепенно? Или вы используете сложные в более общем смысле?   -  person Justin Cave    schedule 16.07.2009
comment
Я имел в виду сложный в общем смысле - например, во многих соединенных таблицах, множестве вложенных табличных выражений, групповых байтах и ​​т. Д. Я не знаю достаточно Oracle, чтобы знать кругооборот, который определяет, можно ли это делать постепенно. Между прочим, при дальнейшем чтении появилась подсказка driving_site. Я думал, что это может быть именно то, что мне нужно, но я не думаю, что это можно сделать в определении представления (то есть внутри DML).   -  person Evan    schedule 16.07.2009

Ответы (2)


arrow_upward
4
arrow_downward

У меня не было бы ничего слишком сложного в базе данных Core. Вы бы увеличили нагрузку на основную базу данных и потенциально перетащили бы намного больше данных.

Рассматривали ли вы возможность репликации основных таблиц в среду отчетов (простая репликация) с помощью MV, построенных на основе этих реплицированных таблиц. SQL-запросы к ядру должны быть проще, объемы данных от ядра до отчетов должны быть меньше, а сложные MV управляются в единой базе данных.

person Gary Myers    schedule 16.07.2009
comment
Ага. хорошая точка зрения. Я думаю, что это то, что нам нужно сделать, но на практике это будет для нас среднесрочной перспективой. Тем более, что объем транзакций невелик. Количество копируемых инкрементальных изменений будет намного меньше, чем периодическая отправка полных наборов результатов. А пока я добивался быстрой победы. с надеждой :-) - person Evan; 16.07.2009
comment
+1 - обычно это лучшая архитектура, если ваши материализованные представления сложны (и я использую сложный, чтобы иметь в виду дорогой SQL в этом контексте). Используйте простые инкрементные MV, чтобы перенести таблицы в базу данных отчетов с небольшим преобразованием или без него, а затем выполнить более дорогостоящие обновления MV в базе данных отчетов из этих таблиц. - person dpbradley; 16.07.2009

arrow_upward
0
arrow_downward

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

person user396181    schedule 19.07.2010