Как подружить банковскую систему Progress OpenEdge и СУБД Oracle

С 1999 года для обслуживания бэк-офиса в нашем банке используется интегрированная банковская система БИСКВИТ на платформе Progress OpenEdge, которая достаточно широко используется во всем мире, в том числе и в финансовом секторе. Производительность данной СУБД позволяет читать до миллиона и более записей в секунду в одной базе базе данных (БД). У нас Progress OpenEdge обслуживает около 1,5 млн депозитов физических лиц и порядка 22,2 млн договоров по активным продуктам (автокредиты и ипотека), а также отвечает за все расчеты с регулятором (ЦБ) и SWIFT.

Используя Progress OpenEdge, мы столкнулись с тем, что нам необходимо подружить ее с СУБД Oracle. Изначально эта связка была «бутылочным горлышком» нашей инфраструктуры — до тех пор, пока мы не установили и не настроили Pro2 CDC — продукт Progress, который позволяет отправлять данные из СУБД Progress в СУБД Oracle напрямую, в онлайн-режиме. В этом посте мы подробно, со всеми подводными камнями расскажем, как эффективно подружить OpenEdge и Oracle.

Как все было: заливка данных в КХД через файловый обмен

Для начала немного фактов о нашей инфраструктуре. Количество активных пользователей базы составляет примерно 15 тысяч. Объем всех продуктивных баз данных, включая реплику и стендбай, — 600 TB, самая крупная БД — 16,5 TB. При этом базы постоянно пополняются: только за последний год добавилось около 120 TB продуктивных данных. Работу системы обеспечивают 150 фронт-серверов на платформе x86. БД размещаются на 21 сервере платформы IBM.

Фронт-системы, различные АБС и банковские сервисы интегрируются с OpenEdge Progress (ИБС БИСКВИТ) через шину Sonic ESB. Выгрузка данных в КХД происходит через файловый обмен. Такое решение до определенного момента времени имело сразу две большие проблемы — низкую производительность выгрузки информации в корпоративное хранилище данных (КХД) и длительное время выполнения сверки данных (реконсиляции) с другими системами.

Поэтому мы начали искать инструмент, который мог бы эти процессы ускорить. Решением обеих проблем как раз и стал новый продукт Progress OpenEdge – Pro2 CDC (Change Data Capture). Итак, начнем.

Устанавливаем Progress OpenEdge и Pro2Oracle

Для работы Pro2 Oracle на Windows-компьютере администратора достаточно установить Progress OpenEdge Developer Kit Classroom Edition, который можно скачать бесплатно. Инсталляционные каталоги OpenEdge по умолчанию:

DLC: C:ProgressOpenEdge
WRK: C:OpenEdgeWRK

Для ETL-процессов необходимы лицензии Progress OpenEdge версии 11.7+ — а именно OE DataServer for Oracle и 4GL Development System. В комплект поставки Pro2 эти лицензии входят. Для полноценной работы DataServer for Oracle с удаленной базой данных Oracle инсталлируется Full Oracle Client.

На сервере Oracle нужно установить версию Oracle Database 12+, создать пустую базу данных и добавить пользователя (назовем его cdc).

Для инсталляции Pro2Oracle скачиваем свежий дистрибутив из центра загрузки Progress Software. Распаковываем архив в каталог C:Pro2 (для настройки Pro2 в Unix используется тот же самый дистрибутив и применяются такие же принципы настройки).

Создание репликационной базы данных cdc

Репликационная база данных cdc (repl) используется Pro2 для хранения конфигурационной информации, в том числе репликационной карты, названий реплицируемых баз данных и их таблиц. Здесь также содержится репликационная очередь, состоящая из заметок о факте изменения строки таблицы в исходной базе данных. Данные из репликационной очереди используются ETL-процессами для идентификации строк, которые необходимо скопировать в Oracle из исходной базы данных.

Cоздаем отдельную базу cdc.

Порядок действий для создания базы

1. На сервере баз данных создаем каталог для бд cdc — например, на сервере /database/cdc/.
2. Создаем пустышку для базы cdc: procopy $DLC/empty cdc
3. Включаем поддержку больших файлов: proutil cdc -C EnableLargeFiles
4. Подготавливаем скрипт старта базы данных cdc. Параметры старта должны быть аналогичны параметрам старта реплицируемой базы данных.
5. Выполняем старт базы данных cdc.
6. Подключаемся к базе данных cdc и загружаем схему Pro2 из файла cdc.df, которая входит в комплект поставки Pro2.
7. В базе данных cdc создаем следующих пользователей:

pro2adm – для подключения из административной панели Pro2;
pro2etl – для подключения ETL-процессов (ReplBatch);
pro2cdc – для подключения CDC-процессов (CDCBatch);

Активация OpenEdge Change Data Capture

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

Порядок действий на примере для базы данных bisquit

1. Копируем из каталога C:Pro2db файл cdcadd.st в каталог исходной базы данных bisquit.
2. Описываем в cdcadd.st экстенты фиксированного размера для областей «ReplCDCArea» и «ReplCDCArea_IDX». Добавлять новые области хранения можно в онлайне: prostrct addonline bisquit cdcadd.st
3. Активируем OpenEdge CDC:
   proutil bisquit -C enablecdc area «ReplCDCArea» indexarea «ReplCDCArea_IDX»
4. В исходной базе данных необходимо создать следующих пользователей для идентификации работающих процессов:
   a. pro2adm – для подключения из административной панели Pro2.
   b. pro2etl – для подключения ETL-процессов (ReplBatch).
   c. pro2cdc – для подключения CDC-процессов (CDCBatch).

Создание Schema Holder для DataServer for Oracle

Далее нам необходимо на сервере, где будут реплицироваться данные из СУБД Progress в СУБД Oracle, создать базу Sсhema Holder. DataServer Sсhema Holder – это пустая база данных Progress OpenEdge без пользователей или прикладных данных, содержащая карту соответствий исходных таблиц и внешних, оракловых таблиц.

База Schema Holder для Progress OpenEdge DataServer for Oracle для Pro2 должна располагаться на сервере ETL-процессов, она создается отдельно для каждого филиала.

Как создать Schema Holder

1. Распаковываем дистрибутив Pro2 в каталог /pro2
2. Создаем и переходим в каталог /pro2/dbsh
3. Создаем базу данных Schema Holder с помощью команды procopy $DLC/empty bisquitsh
4. Выполняем конвертацию bisquitsh в необходимую кодировку — например в UTF-8 если базы данных Oracle имеют кодировку UTF-8: proutil bisquitsh -C convchar convert UTF-8
5. После создания пустой базы данных bisquitsh подключаемся к ней в однопользовательском режиме: pro bisquitsh
6. Переходим в Data Dictionary: Tools -> Data Dictionary -> DataServer -> ORACLE Utilities -> Create DataServer Schema
7. Запускаем Schema Holder
8. Настраиваем брокера Oracle DataServer:
   a. Старт AdminServer.
   proadsv -start
   b. Старт брокера Oracle DataServer
   oraman -name orabroker1 -start

Настраиваем административную панель и репликационную схему

С помощью административной панели Pro2 конфигурируются параметры Pro2, включая настройку репликационной схемы и генерацию программ ETL-процессов (Processor Library), программы первичной синхронизации (Bulk-Copy Processor), репликационные триггеры и политики OpenEdge CDC. Здесь также есть первичные средства мониторинга и управления ETL- и CDC- процессами. Первым делом настраиваем файлы параметров.

Как настроить файлы параметров

1. Переходим в каталог C:Pro2bpreplScripts
2. Открываем на редактирование файл replProc.pf
3. Добавляем параметры подключения к репликационной базе данных cdc:
   # Replication Database
   -db cdc -ld repl -H <имя хоста основных БД> -S <порт брокера БД cdc>
   -U pro2admin -P <пароль>
4. Добавим в replProc.pf параметры подключения к исходным базам данных и Schema Holder в виде файлов параметров. Название файла параметров должно соответствовать названию подключаемой исходной базы данных.
   # Connect to all replicated source BISQUIT
   -pf bpreplscriptsbisquit.pf
5. Добавим в replProc.pf параметры подключения к Sсhema Holder.
   #Target Pro DB Schema Holder
   -db bisquitsh -ld bisquitsh
   -H <имя хоста ETL-процессов>
   -S <порт брокера biskuitsh>
   -db bisquitsql
   -ld bisquitsql
   -dt ORACLE
   -S 5162 -H <имя хоста брокера Oracle>
   -DataService orabroker1
6. Сохраняем файл параметров replProc.pf
7. Далее нужно создать и открыть на редактирование файлы параметров для каждой подключаемой исходной базы данных в каталоге C:Pro2bpreplScripts: bisquit.pf. В каждом pf -файле прописываются параметры подключения к соответствующей базе данных, например:
   -db bisquit -ld bisquit -H <имя хоста> -S <порт брокера>
   -U pro2admin -P <пароль>

Для настройки ярлыков Windows нужно перейти в каталог C:Pro2bpreplScripts и отредактировать ярлык «Pro2 – Administration». Для этого откроем свойства ярлыка и в строке Start in укажем инсталляционный каталог Pro2. Аналогичную операцию нужно проделать для ярлыков «Pro2 – Editor» и «RunBulkLoader».

Настройка Pro2 Administration: загрузка первичной конфигурации

Запускаем консоль.

Переходим в «DB Map».

Чтобы связать базы данных в Pro2 – Administration, переходим на вкладку DB Map. Добавляем маппинг исходных баз данных – Schema Holder – Oracle.

Переходим на вкладку Mapping. В списке Source Database по умолчанию выбрана первая подключенная исходная база данных. Справа от списка должна быть надпись All Databases Connected — выбранные базы подключены. Ниже слева должен быть виден список таблиц Progress из bisquit. Справа — список таблиц из базы Oracle.

Создаем SQL-схемы и базы данных в Oracle

Для создания репликационной карты нужно сначала сгенерировать SQL-схему в Oracle. В Pro2 Administration выполняем пункт меню Tools -> Generate Code -> Target Schema, затем в диалоговом окне Select Database выделяем одну или несколько исходных баз данных и переносим их вправо.

Нажимаем OK и выбираем каталог для сохранения SQL-схем.

Далее создаем базу. Это можно сделать, например, через Oracle SQL Developer. Для этого подключаемся к оракловой базе и загружаем схему для добавления таблиц. После изменения состава таблиц Oracle нужно обновить SQL-схемы в Schema Holder.

После успешного завершения загрузки выходим из БД bisquitsh и открываем административную панель Pro2. На вкладке Mapping справа должны появиться таблицы из базы Oracle.

Маппинг таблиц

Для создания репликационной карты в административной панели Pro2 идем на вкладку Mapping, выбираем исходную базу данных. Кликаем по Map Tables, выделяем слева Select Changes таблицы, которые должны реплицироваться в Oracle, переносим их направо и подтверждаем выбор. Для выбранных таблиц карта будет создана автоматически. Повторяем операцию для создания репликационной карты для других исходных БД.

Генерация библиотеки процессора репликации Pro2 и программ процессора массовой загрузки (Bulk-Copy)

Библиотека процессора репликации (Processor Library) предназначена для специальных репликационных процессов (ETL), которые обрабатывают репликационную очередь Pro2 и передают изменения в базу данных Oracle. Программы библиотеки процессора репликации после генерации автоматически сохраняются в каталог bprepl/repl_proc (параметр PROC_DIRECTORY). Для генерации библиотеки процессора репликации идем в Tools -> Generate Code -> Processor Library. После завершения генерации программы появятся в каталоге bprepl/repl_proc.

Программы процессора массовой загрузки применяются для синхронизации исходных баз данных Progress с целевой базой данных Oracle на основе языка программирования Progress ABL (4GL). Для их генерации идем в пункт меню Tools -> Generate Code -> Bulk-Copy Processor. В диалоговом окне Select Database выделяем исходные БД, переносим в правую часть окна и жмем OK. После завершения генерации программы появятся в каталоге bpreplrepl_mproc.

Настраиваем репликационные процессы в Pro2

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

Информация о состоянии репликационных потоков отображается на экране Pro2 Administration во вкладке Monitor в секции Replication Status. Подробное описание значений параметров можно найти в документации Pro2 (каталог C:Pro2Docs).

Создаем и активируем политики CDC

Политики — это набор правил для механизма OpenEdge CDC, согласно которым выполняется отслеживание изменений в таблицах. На момент написания поста Pro2 поддерживает только политики CDC с уровнем 0, то есть отслеживается только факт изменения записи.

Для создания политики CDC на административной панели переходим на вкладку Mapping, выбираем исходную базу данных и щелкаем по кнопке Add/Remove Policies. В открывшемся окне Select Changes выбираем в левой части и переносим в правую таблицы, для которых необходимо создать или удалить политику CDC.

Для активации снова открываем вкладку Mapping, выбираем исходную базу данных и кликаем по кнопке (In)Activate Policies. Выделяем и переносим в правую часть таблицы, политики которых необходимо активировать, жмем OK. После этого они помечаются зеленым цветом. С помощью (In)Activate Policies также можно деактивировать политики CDC. Все операции выполняются онлайн.

После активации политики CDC заметки об измененных записях сохраняются в область хранения «ReplCDCArea» в соответствии с исходной базой данных. Эти заметки будут обрабатываться специальным процессом CDCBatch, который на их основе будет создавать заметки в репликационной очереди Pro2 в базе данных cdc (repl).

Таким образом, на репликацию у нас образуются две очереди. Первая очередь – CDCBatch: из исходной базы данные сначала попадают в промежуточную базу CDC. Вторая очередь – когда из базы CDC данные переливаются уже в Oracle. Это особенность текущей архитектуры и самого продукта — пока разработчики не смогли наладить прямую репликацию.

Первичная синхронизация

После включения механизма CDC и настройки сервера репликации Pro2 нам необходимо запустить первичную синхронизацию. Команда запуска первичной синхронизации:

/pro2/bprepl/Script/replLoad.sh bisquit table-name

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

Старт репликационных процессов

Для запуска репликационных процессов нужно выполнить скрипт replbatch.sh. Перед стартом — убедиться в наличии скриптов replbatch для всех потоков — replbatch1, replbatch2 и т.д. Если все на месте, открываем командную строку (например, proenv), переходим в каталог /bprepl/scripts и выполняем старт скрипта. В административной панели проверяем, что соответствующий процесс получил статус RUNNING.

Результаты

После внедрения у нас сильно ускорилась выгрузка информации в корпоративное хранилище данных. Данные самостоятельно попадают в Oracle в режиме онлайн. Не нужно тратить время на выполнение каких-то долгоиграющих запросов для сбора данных с разных систем. К тому же в этом решении процесс репликации умеет сжимать данные, что также положительно сказывается на скорости. Теперь ежедневная сверка системы БИСКВИТ с другими системами стала занимать 15-20 минут вместо 2-2,5 часов, а полная сверка — несколько часов вместо двух суток.

Источник: habr.com