Materialized View with Streams

Действительно, не вполне очевидно, когда какую из технологий следует использовать. Однако если прочитать документацию, в ней можно найти подсказку.

"
Unlike Oracle Streams replication, materialized views do not continuously replicate data at all times. A materialized view is a replica of a table or a subset of a table that can be refreshed to a transactionally consistent point in time. During a refresh, only the final values of the changed rows are pulled down and applied to the materialized view, no matter how many updates were applied to the master table. This reduces the amount of time that the remote site must be connected to the master site.
"

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

Однако, уже в 10.2 была сделана пропогация queue-queue, которая умеет бороться с закрытием db link, переживает его отсутствие, а с помощью dbms_aqadm.alter_propogation_schedule можно изобразить передачу данных по расписанию в стиле MV.

Конечно, настройка Streams через API - дело очень не простое, мы будем проходить его почти 3 дня. Процедуры dbms_streams_adm.maintain* - величайшее достижение в streams'ологии, когда за 1 вызов делается все, что необходимо, но с параметрами по умолчанию.

Однако, вернемся у теме сообщения. Мое резюме такое - если Вам надо 1 раз в день перекидывать изменения по одной табличке из одного филиала в другой - используйте MV. Если у Вас есть более серьезная задача по репликации данных, эти данные поддерживаются streams, в разных режимах, с разным расписанием - от Streams Вам не уйти.

Комментариев нет:

Отправить комментарий