18 апр. 2022

Вашему вниманию – материал о нашем полезном опыте использования Oracle GoldenGate (OracleGG). Это комплексная программная платформа для интеграции и репликации данных, входящая в пакет продуктов, по которым мы оказываем расширенную поддержку. Почему мы рекомендуем и используем OracleGG, как мы это делаем и что это дает нашим клиентам?

OracleGG: интергационное решение для репликации данных

В нашем предыдущем материале, посвященном OracleGG, мы подробно останавливались на описании возможностей этого продукта – что собой представляет, почему и для чего используется (статья доступна по ссылке). Вкратце повторимся: OracleGG обеспечивает интеграцию данных (сбор, маршрутизацию, преобразование, проверку и доставку данных в операционные и аналитические системы) посредством непрерывной репликации данных. Этот процесс позволяет существенно минимизировать нагрузку на источник данных посредством распределения этой самой нагрузки между целевыми серверами (приемниками).

При использовании OracleGG обеспечивается:

• Взаимодействие разнородных сред, репликация данных между разнородными системами.
• Устойчивость к сбоям и прерываниям в работе, сохранение транзакционной целостности реплицируемых данных.
• Гарантия доступности критических систем в режиме 24/7 без необходимости остановки систем-источников.
• Перемещение данных с высочайшей скоростью при низкой нагрузке и задержке менее секунды.

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

Архитектура

Схема однонаправленной репликации данных (источник → приемник)
приведена на рисунке 1.

 
Рис. 1.    Схема репликации на основе хаб-архитектуры

Первый процесс: экстрактор анализирует оперативные и архивные журналы транзакций по списку таблиц и условия, описанные в конфигурационном файле для экстрактора. Затем найденные данные в определенном формате отправляются в промежуточные trail-файлы.
Второй процесс: Data Pump передает trail-файлы с одного хоста на другой, при этом файлы могут компрессироваться и шифроваться. Использование Data Pump опционально и в хаб-архитектуре, как правило, не используется. Однако бывают задачи, когда необходимо вывести некую логику (процессы) за пределы экстрактора и репликатора.
Третий процесс: репликатор читает информацию из файлов, формирует SQL statements и отправляет их в БД-приемник, где они применяются на целевых таблицах. 

Опыт использования OracleGG в компании CS

Выполненные проекты компании:

• Репликация из базы Oracle в базу IBM DB2.
• Репликация из базы Oracle в базу Oracle (один из примеров реализации приведен на рисунке 2).

 
Рис. 2.    Интеграция базы данных Б2 с хранилищем данных

Экстрактор работает в интеграционном режиме, то есть часть процесса осуществляется непосредственно в БД, при этом выполняется прямое чтение оперативного журнала транзакций. Найденные изменения записываются в trail-файлы и считываются репликатором. Преобразуются в SQL statements и отправляются на целевую базу. OracleGG-хаб коммуницирует с базой-источником и базой-приемником посредством обычного TNS-протокола, но с настроенным Transparent Application Failover (TAF). Это обусловлено необходимостью прозрачного переключения для OracleGG между основной базой и Standby, как на БД-источнике, так и на БД-приемнике.
Поскольку это промышленное решение, то у основного OracleGG-хаба имеется и резервный сервер. Каждые пять минут он синхронизируется с основным сервером, синхронизация реализована посредством использования rsync.

Использование OracleGG в разных целях:

• OracleGG выполняет перенос изменений данных, при этом OracleGG не синхронизирует данные. Например, при добавлении некой таблицы репликации OracleGG переносит только изменения, которые осуществляются в этой таблице. То есть данные, которые эта таблица содержала до изменений, не синхронизируются.
• OracleGG располагает возможностью преобразования данных, но он не является ETL-инструментом. Для ETL-задач необходимо использовать другие инструменты, например Oracle Data Integrator (ODI). Использование OracleGG для преобразования данных приводит к низкой производительности репликационного процесса.
• Варианты нештатного применения OracleGG:
  • Для восстановления данных. Пожалуй, каждый админ сталкивался с такой задачей, как восстановление случайно удаленных записей в ситуации, когда некий пользователь удалил из одной или нескольких таблиц какое-то количество строк, и через время выясняется, что восстанавливать данные из флешбека уже поздно. Как правило, в таких случаях на соседнем хосте выполняется неполное восстановление БД из резервной копии до точки удаления данных, затем из восстановленной БД нужные строки переносятся в промышленную базу. То есть для восстановления нескольких строк выполняется титаническая работа: поиск хоста с достаточным объемом свободного места, восстановление терабайтов базы… Это весьма ресурсоемкое и громоздкое решение, при том что с помощью OracleGG такую задачу можно решить гораздо проще, быстрее и с наименьшими ресурсными затратами. Для этого используются всего лишь конфигурационные файлы экстрактора и репликатора, а также один или несколько архивных логов, в которых имели место удаления.
  • Для выгрузки данных в файлы разных форматов, например в CSV-файл. Так как это один из универсальных форматов представления данных, то эти данные можно трансформировать и переносить куда угодно. Более того, если в OracleGG нет какой-то поддерживаемой базы данных, то целесообразно использовать CSV-файл, в котором, кроме столбцов с данными, можно указать и тип действия (удаление, вставка, изменение), а также написать программу парсинга, анализирующую данный файл с формированием SQL statement для целевой базы данных.

Наши предложения для заказчиков

Решения для репликации данных: репликация данных АБС Б2 с различными системами, например сторонним клиент-банком, хранилищем CS::BM и другими.
Решения для масштабирования:

• Односторонняя репликация: разделение АБС Б2 на оперативную (транзакционную) и отчетную (архивную) систему.
• Взаимная репликация: вынесение из АБС Б2 тяжелых вычислительных процессов на другую платформу.
• Комбинация эти двух архитектур.
• Вынесение на отдельный сервер системы управленческого учета ISMA и т.д.

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

Для получения более детальной информации, а также для приобретения услуг и решений по поддержке продуктов Oracle обращайтесь в отдел компании CS CoreBanking – Sales (Oracle): [email protected].
Кроме того, мы рады предоставить подробные презентационные материалы, предложенные вниманию наших клиентов на онлайн-встрече 02.12.2021 г. Для получения материалов встречи (видеозаписи и презентации), пожалуйста, отправьте запрос на адрес электронной почты [email protected].