В настоящее время при построении многих автоматизированных систем возникает проблема синхронизации данных из нескольких источников информации.
Одним из способов решения этой проблемы является репликация.
В этой теме я расскажу об одной из таких проблем и о том, как можно решить эту проблему с помощью технологии Oracle Streams.
Абстрактный
Проблема синхронизации данных из нескольких источников информации — достаточно нетривиальная задача с весьма неоднозначным решением.Подобные проблемы возникают довольно часто, но универсального решения подобной проблемы на данный момент практически не существует. Практически все готовые системы репликации данных работают со значительными ограничениями на структуру и способы хранения и изменения данных.
Введение в проблему
На данный момент задержек с синхронной репликацией нет, но это, в свою очередь, влияет на пропускную способность транзакций и возможности системы в целом.Поэтому неудивительно, что большинство пользователей выбирают асинхронную репликацию.
Задача состоит в том, чтобы разработать систему асинхронной репликации, которая могла бы гарантировать низкую фиксированную задержку и поддерживать полную пропускную способность транзакций базы данных.
Технология потоков Oracle
Oracle Streams — универсальный гибкий механизм обмена информацией между серверами в многосерверной архитектуре.Позволяет одновременно реализовать репликацию, обмен сообщениями, загрузку хранилища данных, работу с событиями и поддержку резервной базы данных.
Данные следуют по заданным пользователем маршрутам и доставляются по назначению.
Результатом является механизм, который обеспечивает большую функциональность и гибкость, чем традиционные решения для хранения, распространения данных и совместного использования их с другими базами данных и приложениями.
Oracle Streams — это отдельная информационная инфраструктура, состоящая из процессов захватывать , распространение И применять информация.
ЛКР, ЧР
В контексте Oracle Streams информационное представление любых изменений, внесенных в базу данных, называется LCR (логическая запись изменений).LCR представляет собой обобщенное представление всех возможных изменений, представленных в базе данных.
ЧР (запись изменения) – запись изменения, используемая для обозначения конкретного изменения в базе данных.
Правила и трансформации
Пользователь также имеет возможность определять соответствия между LCR и набором правил.Эти правила оценивают все изменения, внесенные в базу данных, и отфильтровывают несоответствующие LCR. Например, следующее правило определяет только изменения DML в таблице SCOTT.EMP.
Правила определяются таким же образом для изменений DDL. Кроме того, к правилам можно прикрепить преобразования.:dml.get_object_owner()=’SCOTT’ and :dml.get_object_name()=’EMP’
Преобразования используют хранимые процедуры пользователя или системы и автоматически изменяют любые LCR , что удовлетворяет условиям используемого правила.
Очереди
Очереди сохраняют LCR по мере их перемещения по системе, т. е.находятся «между» процессами Oracle Streams. Одна из первых задач при настройке Oracle Streams — создать очереди и связать их с процессами Oracle Streams. Для каждого процесса Oracle Streams можно определить набор правил и преобразований, связанных с этими правилами, чтобы иметь возможность фильтровать информацию на «входе» и «выходе» процесса.
Очереди поддерживают три типа операций: ставить в очередь — построение LCR в очереди, просматривать - просмотр LCR и снимать с очереди – удаление.
Захват, распространение и применение
Три основных процесса Oracle Streams:- захватывать ,
- распространение ,
- применять .
- чтение изменений, содержащихся в журналах транзакций,
- Преобразование CR в LCR,
- постановка в очередь LCR.
- просмотр ЛКР,
- перенос LCR из одной очереди в другую, причем очереди могут находиться как в одной базе данных, так и в разных,
- удаление ЛКР.
- извлекает полученные LCR из очереди,
- вносит изменения в базу данных в соответствии с ЛКР,
- удаляет LCR из очереди.
Обзор
На рисунке показана общая схема репликации на базе Oracle Streams:
В примере показан вариант односторонней репликации, но возможны и другие варианты.
Например, мы можем добавить еще один набор процессов захвата, распространения и применить процессы в противоположном направлении для достижения двусторонней репликации.
Таким же образом, соединив соответствующие процессы, можно сформировать любую топологию репликации.
Дополнительная регистрация
Как уже говорилось выше, основой каждого LCR является CR, несущий минимальное количество информации.Обычно это измененные атрибуты и идентификатор строки, которые можно получить.
Когда происходит изменение данных, т. е.
изменение DML, LCR должен содержать первичные ключи изменяемых строк.
Но возможно, что полученные данные используются в параллельных процессах, и тогда могут понадобиться другие, неключевые столбцы.
Таким образом, CR может включать дополнительные, неключевые столбцы.
Это необходимо для того, чтобы эти столбцы оставались неизменными, а также для усиления соответствия строк источника и назначения.
Добавление этих столбцов в журналы транзакций называется дополнительным журналированием.
Применить обработчик
При решении некоторых задач с использованием Oracle Streams будет удобно на лету менять полученный LCR с помощью написанной пользователем хранимой процедуры под названием применить обработчик .Например, это необходимо, когда репликация происходит между схемами с разными именами и, таким образом, исходный LCR не может быть правильно применен в пункте назначения.
Отсюда следует, что задача обработчика применения — преобразовать изменения в источнике, представленном как LCR, чтобы их можно было правильно применить в получателе.
Конфликты
Асинхронная репликация, как и синхронная репликация, имеет свои недостатки.Основным недостатком асинхронной репликации является возможность несогласованности данных, также известная как конфликты данных.
Они возникают, когда пользователи вносят изменения в место назначения, и эти изменения конфликтуют с исходными данными.
Другими словами, после изменений, внесенных пользователем, данные источника и назначения не совпадают. Эти возможные несоответствия требуют анализа и разрешения.
Такие конфликты чаще всего возникают при обновлении данных в источнике.
При анализе из LCR берутся «старые» исходные данные, т.е.
данные, существовавшие до изменения, внесенного конкретным LCR. Затем во время приложения они сравниваются с текущими значениями в обновленной строке на приемнике.
Помимо пользовательских проверок соответствия, база данных также отслеживает нарушения ссылочной целостности, уникальности и других ограничений.
Кроме того, Oracle Streams включает встроенный обработчик конфликтов для анализа.
Двумя основными «режимами» этого обработчика являются «максимальное значение» и «перезапись».
В первом режиме при возникновении конфликта сравниваются старое и новое значения и записывается наибольшее; для строк большее значение выбирается с использованием кодов ASCII; во втором всегда записывается новое значение.
Пользователи также могут самостоятельно обрабатывать конфликты, написав хранимую процедуру, которая будет разрешать возникающие конфликты.
Но практика показывает, что в большинстве случаев «режимы» встроенного обработчика подходят под требования большинства пользователей.
Заключение
В этой статье я постарался описать основные процессы и объекты Oracle Streams, которые на мой взгляд могут кого-то заинтересовать.Я не вдавался в подробности, а описал все поверхностно.
Более подробную информацию всегда можно найти в официальной документации.
Главное знать, что читать.
Теги: #Распределенные системы #oracle #База данных Oracle #репликация базы данных
-
Заработок Денег: Бесплатный Контент Статьи
19 Oct, 24 -
Загадочное Число 6174.
19 Oct, 24 -
Легальный Проект Обмена Криптовалют
19 Oct, 24 -
«Ведомости» Тоже Проиграли
19 Oct, 24 -
Hazelcast 3.3 — Что Нового?
19 Oct, 24
