Вашему вниманию – материал о нашем полезном опыте использования 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]
