Pull to refresh

Асинхронная репликация с помощью Oracle Streams

Reading time 5 min
Views 19K
В настоящее время при построении многих автоматизированных систем возникает проблема синхронизации данных по нескольким источникам информации. Один из способов решения этой проблемы — репликации.

В данном топике я расскажу об одной из таких проблем и о том, как можно решить эту проблему с помощью технологии Oracle Streams.

Абстрактно

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

Введение в проблему

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

Технология Oracle Streams


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

LCR, CR

В контексте Oracle Streams, информационное представление любого изменения, сделанного в базе данных, называется LCR (logical change record). LCR – это обобщенное представление всех возможных изменений, представленных в базе данных.
CR(change record) — запись изменения, используется для того, чтобы обозначить конкретное изменение в базе.

Rules and transformations

Также пользователь имеет возможность определять соответствия между LCR и набором правил. Эти правила оценивают все изменения, произведенные в базе данных, и проводят фильтрацию несоответствующих LCR.

Например, следующее правило определяет только DML изменения таблицы SCOTT.EMP

:dml.get_object_owner()=’SCOTT’ and 
:dml.get_object_name()=’EMP’

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

Queues

Очереди осуществляют хранение LCR, когда они двигаются в системе, т.е. находятся «между» процессами Oracle Streams.
Одна из первоочередных задач при настройке Oracle Streams — создать очереди и привязать их к процессам Oracle Streams. Для каждого процесса Oracle Streams может быть определен набор правил и связанных с этими правилами трансформаций для того, чтобы иметь возможность фильтровать информацию на «входе» и «выходе» процесса.
Очереди поддерживают три типа операций, enqueue — построение LCR в очередь, browse — просмотр LCR и dequeue – удаление.

Capture, Propagation and Apply

Тремя основными процессами Oracle Streams являются:
  • capture,
  • propagation,
  • apply.

Основные задачи процесса capture:
  • считывание изменений, содержащихся в журналах транзакций,
  • преобразование CR в LCR,
  • постановка LCR в очередь.

Так же как и capture, процесс propagation выполняет 3 основных задачи:
  • просмотр LCR,
  • передача LCR из одной очереди в другую, причем очереди могут находится как на одной базе данных, так и на разных,
  • удаление LCR.

Apply процесс:
  • извлекает принятые LCR из очереди,
  • производит изменения с базой данных в соответствии с LCR,
  • удаляет LCR из очереди.

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

Overview

На рисунке изображена общая схема репликации на основе Oracle Streams:
image

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

Supplemental Logging

Как уже было сказано выше, в основе каждой LCR лежит CR, которая несет минимальное количество информации. Обычно, это возможные к извлечению измененные атрибуты и rowid.
Когда происходит изменение данных, т.е. DML изменение, LCR должен содержать первичные ключи изменяемых строк. Но возможен случай, когда принятые данные применяются в параллельных процессах, и тогда могут понадобиться и другие, не ключевые, колонки. Таким образом, CR может включать дополнительные, не ключевые, колонки. Это нужно для того, чтобы эти колонки оставались неизменными, а также, чтобы усилить проверку соответствия строк источника и приёмника. Добавление этих колонок в журналы транзакций называется supplemental logging.

Apply handler

При решении некоторых задач с помощью Oracle Streams удобно будет изменять принимаемую LCR «на лету» при помощи хранимой процедуры, написанной пользователем и называющейся apply handler.
Например, это необходимо когда репликации происходят между схемами с разными именами и, таким образом, LCR источника не может корректно примениться на приемнике. Отсюда следует, что задачей apply handler является преобразование изменений источника, представленного в виде LCR, так, чтобы они могли корректно применяться на приемнике.

Conflicts

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

При анализе из LCR берутся «старые» данные источника, т.е. данные, которые были до изменения, сделанного конкретным LCR. Затем, во время применения, они сравниваются с текущими значениями в обновляемой строке на приёмнике.

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

Кроме того, для анализа в Oracle Streams содержится встроенный конфликтный обработчик. Двумя основными «режимами» этого обработчика являются «максимальное значение» и «перезапись». В первом режиме при возникновении конфликта сравнивается старое и новое значения и записывается наибольшее, для строк большее значение выбирается с помощью ASCII кодов, во втором – всегда происходит запись нового значения. Также пользователи могут обрабатывать конфликты и сами, написав хранимую процедуру, которая будет решать возникающие конфликты.
Но практика показывает, что в большинстве случаев «режимы» встроенного обработчика подходят для требований большинства пользователей.

Заключение

В настоящей статье я попытался описать основные процессы и объекты Oracle Streams, которые на мой взгляд могут кому-нибудь интересны. В детали я не вдавался, а описал все поверхностно. Более подробно всегда можно прочитать в официальной документации. Главное знать что читать.
Tags:
Hubs:
+3
Comments 3
Comments Comments 3

Articles