Выполнение дистанционного материализованных представлений в Oracle

У меня есть вопрос reagrding Oracle материализованных представлений ...Выполнение дистанционного материализованных представлений в Oracle

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

Ядро базы данных
база данных отчетов

в базе данных отчетов:

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

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

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

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

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

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

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

веселит, Эван

источник

2009-07-16 Evan

Можно ли предположить, что, когда вы говорите «сложный», вы используете его так же, как это делает Oracle, когда речь идет о сложных материализованных представлениях, то есть материализованных представлений, которые не могут обновляться постепенно? Или вы используете «сложный» в более общем смысле? –

Я имел в виду комплекс в общем смысле - как и во многих таблицах, связанных с множеством вложенных табличных выражений, групповых и т. Д. Я не знаю достаточного количества Oracle, чтобы знать, насколько сильна эта критика, которая может быть выполнена поэтапно. Кстати, дальнейшее чтение подбросило подсказку «driving_site».Я думал, что это может быть именно то, что мне нужно - но я не думаю, что это можно сделать в определении вида (т. Е. Внутри DML). – Evan

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

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

источник

2009-07-16 05:18:13

yep. хорошая точка зрения. Я думаю, что это то, что нам нужно сделать, но на практике это будет для нас средним сроком. Тем более, что объем транзакций не огромен. Количество инкрементных изменений, которые будут реплицироваться, будет намного меньше, чем отправка целых наборов результатов периодически. На данный момент я был после «быстрой победы». Надеемся, что :-) – Evan

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

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

источник

2010-07-19 20:10:40 user396181

Выполнение дистанционного материализованных представлений в Oracle

ответ

Смежные вопросы