Oracle Materialized Views Vs Replication на том же сервере БД

Question

Нам нужно запускать отчеты в запланированное время дня. Приложение работает 24 * 7, и поэтому не существует "непикового" времени как такового.

Поэтому запуск отчетов не должен добавлять чрезмерную нагрузку на систему.

Приложение работает в WebSphere v6.1, а база данных - Oracle 10g R2.

В моем распоряжении следующие подходы

1. Набор ненормализованных таблиц, предназначенных для отчетности.
2. Создание материализованных представлений и использование их для отчетов. Мы можем обновлять представления один раз в день.
3. Мы можем создать другую схему и реплицировать таблицы в реальном времени, используя Oracle Data Guard.

(1) невозможно из-за определенных внутренних ограничений.

Мне нужно знать, с точки зрения производительности, что лучше, (2) или (3)?

Я слышал от многих людей, что материализованные представления вначале работают хорошо, но по мере увеличения объемов данных производительность очень плохая.

Любой имеет опыт репликации таблиц на одном и том же сервере БД (но не в разных экземплярах или схемах).

Answer 1

В некоторой степени материализованные представления являются денормализованными таблицами - денормализация - это то, что вы можете определить в операторе SELECT, например, объединения, агрегации и аналитические функции. После первоначального определения MV вы можете добавить в базовую таблицу MV любые индексы, необходимые для достижения необходимой вам производительности.

Сказав это, я думаю, что ваши варианты:

1. Использовать денормализованные таблицы в той же базе данных, которые каким-то образом поддерживаются кодом, который вы пишете - Эта опция обеспечит вам максимальный контроль над процессом загрузки за счет необходимости писать и поддерживать код. Вы также устраните издержки на инфраструктуру отдельного экземпляра. Процесс денормализации и запросы отчетов увеличат требования к ресурсам активной / транзакционной базы данных, и вы должны быть готовы к этому. С помощью этой опции вы также связали доступность приложения для отчетов с доступностью транзакционной системы.
2. Использование MV в той же базе данных - Приведенные выше комментарии об инфраструктуре и накладных расходах ресурсов применимы, но вы получаете преимущество от использования функциональности Oracle MV для планирования (реализовано через DBMS_JOB) и согласованности транзакционного чтения ("" старые "данные все еще видны до тех пор, пока новый SELECT не будет разрешен и зафиксирован).
3. Использовать MV в другой базе данных / экземпляре на том же хосте - Вы получаете некоторое предельное разделение и потенциальную доступность с помощью этой опции, но вы все равно влияете на общие ресурсы хоста базы данных. Более поздние версии Oracle позволяют вам контролировать использование ресурсов в экземпляре до детального уровня, поэтому, по моему мнению, нет веских причин для запуска отдельной базы данных на том же хосте.
4. Использование MV в другой базе данных на другом хосте - Вы можете установить ссылку на БД для транзакционной системы и выполнить обновление MV по ссылке. Вы по-прежнему будете иметь процесс обновления / загрузки MV, влияющий на ресурсы в исходной системе, но все операции с запросами будут изолированы, и у вас будет некоторая степень доступности отчетов во время простоя для исходной системы. Вам нужно будет купить дополнительные лицензии Oracle с этой опцией.
5. Использование экземпляра Data Guard - Недостатки: дополнительные лицензии, повышенная сложность в настройке и администрировании. Преимущества: минимальное влияние на исходную систему, истинная копия системы и, если вы используете логическую, а не физическую репликацию, вы можете создавать дополнительные структуры (представления, индексы и т. Д.) В базе данных Data Guard.

Answer 2

Лучший вариант - использовать другой экземпляр Data Guard (не схема, это не имеет смысла) на другом компьютере. В этом случае вы можете иметь актуальную базу данных, которая не будет мешать работе производственного приложения.

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

Третий вариант, о котором вы не говорите, - это использование Oracle Resource Manager , которое позволяет вам контролировать использование ресурсов с большим количеством возможностей.

В любом случае, Я предпочитаю первый (Data Guard) , потому что у вас есть «Report dabatase» и «live-backup» одновременно.