Таблица 1. Типичные решения для
Таблица 1. Типичные решения для обмена информацией
Купить у разных фирм | Oracle |
Replication Tools | Advanced Replication |
Messaging Software | Advanced Queueing |
Warehouse Loaders | CMC + Loader + WB |
HA, Performance SW | Standby |
Middleware | Integration in iAS |
Event Management apps | ---- |
Notification apps | ---- |
Если у нас есть совокупность приложений, включающая хранилища и витрины данных, оперативные системы, резервные узлы, приложения, использующие обмен сообщениями (как с приложениями Oracle, так и с другими пакетами, например с MQ Series) и т д и между ними надо организовать обмен информацией, то картинка будет выглядеть как на рисунке 1. Т. е. придется поддерживать огромное количество связей, передавать огромное количество информации.
Рис 1. Традиционная интеграция данных
В такую архитектуру трудно встроить приложения, построенные на основе чужих (не Oracle) СУБД, в ней трудно реализовать систему извещения пользователей о событиях и управления событиями (это требует написания программного кода). А если мы во время эксплуатации системы решим, например, не реплицировать в резервную БД изменения отдельных объектов, а поддерживать полноценную копию всей исходной БД, то это потребует большого объема работы со стороны администратора БД, т е наша архитектура не является гибкой.
Поэтому Oracle решил создать новый универсальный гибкий механизм обмена информацией, свободный от этих недостатков и позволяющий одновременно реализовать репликацию, обмен сообщениями, загрузку хранилищ данных, работу с событиями, поддержку резервной БД (логический Standby). Этот механизм называется Oracle Streams.
Oracle Streams состоит из трех основных элементов:
- захват изменений (Capture)
- складирование, хранение и распространение изменений (Staging)
- применение изменений (Consumption или Apply)
Теперь в исходной системе вся необходимая для различных механизмов обмена информация автоматически захватывается, упорядочивается, преобразуется в универсальный формат и помещается в область хранения. Далее она автоматически перемещается между областями хранения и в тех целевых узлах, где она нужна, эта информация используется Apply процессами, которые выполняют репликацию или загружают хранилище данных или обновляют резервную БД и т д. Приложениям – потребителям достаточно просто подписаться на необходимую им информацию и они будут ее автоматически получать, а Apply процессы будут ее автоматически применять. Мы видим, что теперь картинка с рисунка 1 значительно упростилась (см 2). Количество связей уменьшилось, механизм упростился. Заказчик теперь должен покупать, изучать, конфигурировать и поддерживать только один продукт, добавление новых публикаторов (добавляющих информацию об изменениях в поток) и новых подписчиков (потребляющих информацию из потока) осуществляется легко, замена одного механизма обмена информацией на другой выполняется просто. И главное, падает нагрузка на сеть и эксплуатационную систему. Oracle Streams захватывает информацию об изменениях из журнальных файлов, не нагружая эксплуатационную систему, причем он захватывает и передает ее только один раз, не дублируя информацию. Кстати Oracle Streams входит в состав сервера Oracle без дополнительной платы.
2. Интеграция данных в Oracle Streams
