2004 г.

Oracle Streams - универсальное средство обмена информацией

Mарк Ривкин

Статья была опубликована в журналах "BYTE/Россия" и Oracle Magazine RE

Обмен информацией

При построении современных информационных систем пользователи редко ограничиваются одним компьютером с одной базой данных (БД). Гораздо чаще приходится использовать многосерверные архитектуры. Причины этого кроются в задачах, которые приходится решать, и в архитектурах создаваемых прикладных систем. Например, типичная архитектура информационной системы крупного предприятия имеет такие элементы, как центральная БД и БД филиалов или регионов. И эти узлы должны обмениваться информацией. Другой пример – интеграция старых информационных систем, успешно работающих на предприятии, и вновь создаваемых на других компьютерах информационных систем. Типичный пример многосерверной архитектуры возникает и в тех случаях, когда в организации создается хранилище данных, собирающее информацию из нескольких оперативных систем, или для повышения надежности прикладной системы предприятие организует резервные информационные центры. Информацией могут обмениваются не только различные СУБД (возможно выпускаемые различными фирмами). Информацией должны обмениваться и приложения и пользователи. Причем они обмениваются не только информацией об изменении данных в одной из систем, но также информацией о выполненных транзакциях, произошедших событиях, сообщениями и т д.

Если в старых системах приложение, которому требовалась информация из другого приложения, кодировалось так, что оно просто время от времени явно запрашивало это второе приложение об изменениях, то в современных информационных системах необходимо, чтобы процесс обмена информацией происходил автоматически, не требовал программирования. Надо чтобы передавалась только та информация, которая нужна, в то время и в то место, когда и где она действительно нужна, не перегружая при этом сеть и исходную БД.

Многие компании для решения задачи обмена информацией приобретают специальные программные пакеты разных фирм для поддержки этих функций. В этом случае им приходится приобретать сервер репликации, пакет для работы с очередями сообщений, средства загрузки данных в хранилища и витрины данных, ПО для нотификации (извещения о событиях) и управления событиями и т д. Иногда достаточно приобрести только часть этих средств. Не будем говорить о стоимости этого дополнительного программного обеспечения и недостатках многих из этих пакетов. Главная проблема здесь – интеграция. Сложность интеграции этих разнородных систем с различной архитектурой, языками, средствами доступа и т д настолько велика, что большинство интеграционных проектов оканчивается неудачей.

Пользователям СУБД Oracle несколько проще, поскольку средства для репликации, обмена сообщениями, организации резервной БД, захвата изменений и загрузки хранилищ и витрин данных входят в состав сервера Oracle 9i без дополнительной платы (см. табл. 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

Архитектура Oracle Streams

Oracle Streams реализован на основе системы обмена очередями сообщений Oracle Advanced Queuing. При конфигурировании Oracle Streams в каждой БД, участвующей в обмене информацией, запускаются дополнительные процессы и создаются дополнительные структуры данных, необходимые для поддержки потоков информации.

Единица информации, помещаемая в поток, называется событием (event). Этот универсальный элемент потока может быть либо стандартного типа (он называется LCR – Logical Change Record) и содержит информацию о DDL или DML изменениях в исходной БД, либо произвольного типа – тогда это просто пользовательское сообщение, за помещение которого в поток и извлечение из потока отвечают пользовательские программы. Т. е. в одном потоке можно передавать как информацию об изменениях данных и структур, так и произвольные сообщения. Причем в один и тот же поток могут помещать свои элементы различные БД и приложения. А в целевых узлах из этого потока будет извлечены только те элементы, которые нужны данному узлу.

Поток данных может течь как внутри одной БД (таким образом удобно поддерживать копии объектов, материализованные представления (snapshots), реализовывать систему извещения о событиях), так и между различными БД. В этом случае область хранения (Staging Area) целевой БД просто “подписывается” на информацию из Staging Area исходной БД. После этого необходимая информация автоматически течет из исходной БД в целевую.

Захват изменений

Захват информации об изменениях и сообщений в исходном узле может выполняться явно или неявно. В случае неявного захвата сконфигурированный процесс захвата (Capture) автоматически считывает из оперативных или архивных журналов БД (redologs) информацию об изменениях в БД, используя механизм утилиты LogMiner. Далее считанная информация фильтруется в соответствии с заданными условиями захвата (например, захватываются только изменения в конкретных таблицах или схемах, только DDL или только DML изменения и т. д.). Отфильтрованная информация преобразуется в формат LCR и помещается в Staging Area.

В случае явного захвата информации необходимо писать пользовательские приложения, которые захватывают информацию из Oracle или других систем и сами, используя API, помещают эту информацию в Staging Area. Для создания этих приложений можно использовать Java (JMS), C, PL/SQL, SOAP (XML/HTTP), XML/SMTP. Если информация явно помещена в поток в виде LCR, то она может далее автоматически применяться к целевой БД Apply процессами. Если же она помещена в поток в виде сообщений, то необходимо написать процедуру извлечения этих сообщений из потока (очереди) и установить эту процедуру на целевом узле (узлах).

Складирование, хранение и распространение изменений

Вся захваченная информация хранится в областях хранения (Staging Area). Они реализуются в виде очередей сообщений, поэтому для работы с ними можно использовать стандартный API Advanced Queuing. Однако, поскольку в этой очереди хранятся не только сообщения стандартных типов, но и информация об изменениях различных типов данных в БД, Oracle ввел поддержку нового самоописывающегося типа данных Sys.AnyData. В этом типе данных могут храниться самые разные типы информации. Он позволяет совмещать в одной очереди (потоке) различные типы данных. Методы этого объектного типа позволяют извлекать информацию о типе хранящегося экземпляра объекта, сам экземпляр объекта, его элементы, модифицировать экземпляр объекта, преобразовывать другие типы в Sys.AnyData и т д.

Все элементы потока, помещенные в Staging Area, хранятся в ней до тех пор, пока все подписчики, подписавшиеся на эти элементы, не используют их. Напомним, что подписчиками могут быть не только Apply процессы, но и другие Staging Area или пользовательские приложения. Использованные элементы потока автоматически уничтожаются, однако можно отменить уничтожение и оставлять их в Staging Area, например, для выполнения аудита.

При помещении элементов потока в Staging Area, при их извлечении из нее и при перемещении в другую Staging Area можно выполнять преобразование элементов. Преобразования выполняются автоматически, необходимо лишь указать при конфигурировании какие процедуры будут выполнять преобразование и для каких элементов потока эти процедуры надо вызывать. Каждая процедура преобразования получает на входе элемент потока (LCR или сообщение), модифицирует его и возвращает модифицированный элемент потока. Например, такая процедура может изменить формат или тип данных реплицируемой колонки, изменить имя колонки или таблицы и т. д. Это позволяет использовать Oracle Streams для репликации данных между объектами разной структуры.

Применение изменений

Когда поток достигает Staging Area целевой БД, на него “набрасываются” Apply процессы этой целевой БД (если они там имеются), подписавшиеся на этот поток Они извлекают предназначенные для данного узла элементы потока и применяют их к своей БД. Apply процессов в БД может быть несколько. Для извлечения пользовательских сообщений из потока пишутся пользовательские Apply процессы, которые явно извлекают сообщения из потока (очереди). Эти пользовательские приложения пишутся на Java (JMS), C, PL/SQL, SOAP (XML/HTTP), XML/SMTP.

Более интересны, однако, автоматически срабатывающие т н “дефолтные” Apply процессы. Они читают LCRы из потока, преобразуют их в команды DML или DDL и автоматически применяют эти SQL команды к БД. Причем команды SQL могут применяться как к таблицам и объектам локальной БД, так и через Database Link и шлюз (Gateway) к таблицам чужих (не Oracle) СУБД.

Поскольку целевая БД кроме участия в обмене информацией может быть открыта для изменений другими приложениями, мы можем получить ситуацию, когда одни и те же данные одновременно изменены и в исходной и в целевой БД. Т. е. мы сталкиваемся с конфликтами обновления и должны уметь их разрешать. Oracle Streams умеет автоматически определять и разрешать такие конфликты. Имеется ряд стандартных механизмов разрешения конфликтов (берется минимальное или максимальное значение, последнее по времени изменение и т д), можно написать свои собственные процедуры разрешения конфликтов.

Для ускорения работы по применению изменений к БД Apply процесс фактически выступает в роли координатора этой работы. Он порождает параллельно работающие подпроцессы, которые читают LCRы из потока, собирают их в транзакции, а потом параллельно применяют к БД. Если в потоке сосуществуют LCRы из разных узлов, захваченные разными Capture процессами, то для их применения в данном узле надо создать несколько Apply процессов (для каждого Capture – свой Apply).

Кроме того, “дефолтный” Apply процесс может не только формировать команды SQL на основе LCRов, но и выполнять более сложную обработку. В этом случае для него указывается имя пользовательской Apply функции, которая получает LCRы, обрабатывает их и применяет к БД. Эти функции можно писать на PL/SQL, Java, C, C++. Такие функции кроме применения LCR к БД могут, например, выполнять дополнительные преобразования данных, исключать из изменения некоторые колонки, нормализовывать/денормализовывать данные, записывать дополнительную информацию в другие колонки и таблицы (не указанные в LCR) и т д.

Правила

Как уже упоминалось ранее, не все изменения выбираются из журналов БД, не все изменения притекают в конкретные узлы и не все изменения применяются к конкретной БД. Фильтрация изменений реализуется за счет того, что подписка на изменения основана на правилах. Правила регламентируют, какую информацию надо захватывать, транспортировать, применять. Причем эти правила используют содержимое элемента потока, т е мы можем указать, что в конкретный узел попадают только изменения для конкретных объектов. Кроме того, изменение, например, значения поля “Страна” в записи с “UK” на “Russia” приведет к тому, что эти изменения потекут и будут применены не в Англии, а в российских узлах.

Машина правил существует в сервере Oracle независимо от Oracle Streams. Пользовательские приложения, так же как Oracle Streams, могут использовать ее, передавая ей оцениваемую строку и имя набора правил и получая ответ (истина/ложь). Правила описываются пользователем как обычное условие, напоминающее предикат SQL выражения WHERE и являются объектами БД. Из отдельных правил набираются наборы правил , т н RULE SETS, которые машина правил и применяет для оценки. Кстати с помощью правил можно не только отфильтровать изменения, относящиеся к отдельным объектам БД или схемам, DDL или DML операции, но, также, наложить условие на изменения таблицы, применяемые в конкретном узле, порождая, таким образом, разные подмножества одной таблицы в разных БД.

Конфигурирование маршрута потока независимо от конфигурирования Apply процессов конкретных узлов. Благодаря этому и системе правил мы можем управлять движением потока. Например, поток может течь через некоторые узлы не меняя их БД. Это позволяет уменьшить нагрузку на сеть, т к все изменения не текут от исходной БД во все целевые БД, создавая много “широких” потоков. Вместо этого мы имеем широкий поток, который затем расщепляется на несколько более мелких. Например, если в Нью- Йорке в таблицу записываются данные, часть из которых должна быть отреплицирована в БД Англии, часть в БД Италии, а часть в БД Франции, то мы можем направить весь поток из Америки через океан в Европу (в Лондон). Там изменения для Англии будут извлечены и обработаны, а поток расщепится и часть изменений пойдет в Италию, а часть – во Францию (см. рис. 3).

Рис. 3. Расщепление потока

Поскольку Apply процесс БД Oracle может через Database Link и шлюз вносить изменения в чужие БД или передавать сообщения в чужие системы управления сообщениями, а приложения, работающие с чужими СУБД и системами сообщений могут помещать LCRы и сообщения в поток Oracle, механизм Oracle Streams удобно использовать для обмена информацией и интеграции разнородных приложений построенных как на платформе Oracle, так и на платформах других компаний. Шлюз Message Gateway позволяет работать с сообщениями потока Oracle Streams из пакета MQ Series.

Установка, конфигурирование и поддержка Oracle Streams в различных режимах может осуществляться через дружелюбный графический интерфейс штатного инструмента администратора Oracle – Oracle Enterprise Manager.

Преимущества Oracle Streams

Итак Oracle Streams обеспечивает репликацию, обмен сообщениями, поддержку логической резервной БД, загрузку хранилищ и витрин данных, извещение о событиях. Однако он не только реализует эти отдельно существовавшие механизмы обмена информацией, но и обеспечивает им ряд дополнительных преимуществ, которыми они ранее не обладали.

Репликация

В случае репликации используется следующая архитектура:

Неявный захват è хранение è перемещение è неявный дефолтный Apply

Это самый простой вид использования Oracle Streams. Он легко конфигурируется и поддерживает автоматическую асинхронную репликацию многих копий объекта. Причем реплицироваться могут данные как между одинаковыми объектами (весь объект или часть объекта), так данные между объектами с разной структурой (через преобразования или Apply функцию).

Oracle Streams автоматически захватывает, передает и применяет DDL и DDL изменения, определяет и разрешает конфликты, позволяет выполнять репликацию с объектами в чужих СУБД, снижает нагрузку на сеть и эксплуатационную систему по сравнению с обычной репликацией, за счет извлечения информации из журналов.

Загрузка хранилищ и витрин данных

В случае загрузки хранилищ и витрин данных используется следующая архитектура:

Неявный захват è хранение è перемещение è неявный Apply с помощью пользовательской функции

В этом случае обновления захватываются автоматически из оперативной БД. Кроме того, в поток можно помещать информацию об изменениях в чужих СУБД или пользовательские сообщения о функционировании оперативной БД (можно, например, создать хранилище сообщений). Операции очистки и преобразования данных, типичные для хранилищ данных, могут быть выполнены в виде процедур преобразования при помещении/извлечении из/в Staging Area.

Обычно данные из оперативных систем перегружаются в хранилища в пакетном режиме. Между загрузками проходит много времени и хранилище или Operating Data Store (ODS) отстают от БД оперативных систем. В случае Oracle Streams можно организовать непрерывную подпитку хранилища или ODS “тонкой струйкой” изменений, при этом отставание ODS или хранилища от оперативной системы будет минимальным и эту целевую БД можно использовать для получения отчетов или анализа данных почти в реальном времени.

Поскольку изменения захватываются из журналов, нет необходимости давать администраторам хранилища или ODS доступ к оперативным системам, что очень порадует администраторов оперативных систем.

Извещение о событиях

Очень часто необходимо в автоматическом режиме извещать пользователей приложения о каких-либо событиях или изменениях, происходящих в БД или приложении. Например, система Orbitz посылает на пейджер пользователей информацию о задержках авиарейсов. Система CNET Shopper отслеживает изменение цен на товары и при снижении цен извещает об этом пользователей. CRM приложения могут оповещать продавцов о покупках, совершаемых наиболее важными заказчиками.

Oracle Streams позволяет легко создать приложение такого типа в БД. Для этого используется следующая архитектура:

Неявный захват è хранение è явное извлечение из потока

Пользовательская программа извлекает из потока данные об изменениях, формирует на их основе сообщения для пользователей и отправляет эти сообщения на пейджер, телефон, по электронной почте и т д.

Очереди сообщений

Oracle Streams построен на основе системы передачи сообщений Oracle Advanced Queuing и поддерживает все функции развитой системы обмена сообщениями, такие как публикация и подписка на основе правил, очереди со многими потребителями (multi-consumer), что уменьшает загрузку сети, подписка на основе контента сообщения.. Уникальная возможность интеграции в одной очереди данных для репликации и сообщений позволяет реализовать единую модель работы для передачи транзакций и сообщений, единую модель безопасности, повысить надежность системы. Oracle Streams поддерживает автоматическое преобразование информации о DDL и DML операциях в формат сообщений.

В случае работы с сообщениями используется архитектура:

Явный захват è хранение è перемещение è явное извлечение

Построенная на основе Oracle Streams система очередей сообщений позволяет легко интегрировать разнородные системы, легко разрабатывать приложения, обмениваться сообщениями с Message Queuing системами различных фирм.

Резервная БД (Logical Standby)

Для защиты прикладной системы от катастрофических сбоев, приводящих к выходу из строя не отдельного компьютера, а всего вычислительного центра, где находится основная эксплуатационная БД, используются резервные БД, расположенные вдалеке от здания основной БД. Такая резервная БД должна принимать и применять все изменения из основной БД, а в случае катастрофического сбоя быстро и без потерь заменить основную БД. Практически обновление резервной БД – это частный случай репликации, поскольку реплицируются все изменения в БД и изменения передаются в одну сторону – от эксплуатационной БД к резервной БД.

В случае использования Oracle Streams для поддержки резервной БД используется архитектура, несколько отличная от предыдущих. Перенос журналов Oracle (или информации об изменениях) из узла в узел осуществляется вне Oracle Streams с помощью механизма Oracle Data Guard. А вот на узле, где расположена резервная БД, архитектура Oracle Streams имеет следующий вид:

Неявный захват è неявный дефолтный Apply

Oracle Streams позволяет реализовать на резервном узле т. н. Режим логического Standby. Т е резервная БД во время применения изменений открыта на чтение. Изменение производятся за счет применения обычных SQL операций. Поэтому резервная БД может одновременно и догонять основную БД и использоваться для построения отчетов, выполнения аналитических задач и т д, разгружая эксплуатационную БД. Для повышения эффективности выполнения этих дополнительных задач в резервной БД можно создать дополнительные индексы, таблицы, материализованные представления и т д, т е структура может отличаться от структуры эксплуатационной БД. Кроме того, эксплуатационная и резервная БД могут работать на разных платформах (операционная система и компьютер) и даже немного различаться по версиям сервера БД. Для конфигурирования и сопровождения такой логической резервной БД используется графический интерфейс компоненты Oracle Data Guard, входящей в состав Oracle Enterprise Manager.

Таким образом новое средство Oracle сервер для обмена информацией - Oracle Streams обеспечивает удобный гибкий универсальный автоматически работающий механизм интеграции приложений и баз данных.