Oracle Materialized Views против репликации на одном сервере БД

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

Сказав это, я думаю, что у вас есть следующие варианты:

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

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

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

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

В любом случае, я предпочитаю первый (Data Guard), потому что у вас одновременно есть «база данных отчета» и «резервная копия в реальном времени».