![](https://habrastorage.org/getpro/habr/post_images/307/c1d/98d/307c1d98db920948d240ad6101acc1e1.png)
Используя Progress OpenEdge, мы столкнулись с тем, что нам необходимо подружить ее с СУБД Oracle. Изначально эта связка была «бутылочным горлышком» нашей инфраструктуры — до тех пор, пока мы не установили и не настроили Pro2 CDC — продукт Progress, который позволяет отправлять данные из СУБД Progress в СУБД Oracle напрямую, в онлайн-режиме. В этом посте мы подробно, со всеми подводными камнями расскажем, как эффективно подружить OpenEdge и Oracle.
Как все было: заливка данных в КХД через файловый обмен
Для начала немного фактов о нашей инфраструктуре. Количество активных пользователей базы составляет примерно 15 тысяч. Объем всех продуктивных баз данных, включая реплику и стендбай, — 600 TB, самая крупная БД — 16,5 TB. При этом базы постоянно пополняются: только за последний год добавилось около 120 TB продуктивных данных. Работу системы обеспечивают 150 фронт-серверов на платформе x86. БД размещаются на 21 сервере платформы IBM.
![](https://habrastorage.org/getpro/habr/post_images/1a9/f39/b08/1a9f39b085135d52cace5abb4f3f6dce.png)
Фронт-системы, различные АБС и банковские сервисы интегрируются с OpenEdge Progress (ИБС БИСКВИТ) через шину Sonic ESB. Выгрузка данных в КХД происходит через файловый обмен. Такое решение до определенного момента времени имело сразу две большие проблемы — низкую производительность выгрузки информации в корпоративное хранилище данных (КХД) и длительное время выполнения сверки данных (реконсиляции) с другими системами.
![](https://habrastorage.org/getpro/habr/post_images/5ed/b9b/7dc/5edb9b7dc0c77268d2a3d535f5593d80.png)
Поэтому мы начали искать инструмент, который мог бы эти процессы ускорить. Решением обеих проблем как раз и стал новый продукт Progress OpenEdge – Pro2 CDC (Change Data Capture). Итак, начнем.
Устанавливаем Progress OpenEdge и Pro2Oracle
Для работы Pro2 Oracle на Windows-компьютере администратора достаточно установить Progress OpenEdge Developer Kit Classroom Edition, который можно скачать бесплатно. Инсталляционные каталоги OpenEdge по умолчанию:
DLC: C:\Progress\OpenEdge
WRK: C:\OpenEdge\WRK
Для 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.
- На сервере баз данных создаем каталог для бд cdc — например, на сервере /database/cdc/.
- Создаем пустышку для базы cdc: procopy $DLC/empty cdc
- Включаем поддержку больших файлов: proutil cdc -C EnableLargeFiles
- Подготавливаем скрипт старта базы данных cdc. Параметры старта должны быть аналогичны параметрам старта реплицируемой базы данных.
- Выполняем старт базы данных cdc.
- Подключаемся к базе данных cdc и загружаем схему Pro2 из файла cdc.df, которая входит в комплект поставки Pro2.
- В базе данных cdc создаем следующих пользователей:
pro2adm – для подключения из административной панели Pro2;
pro2etl – для подключения ETL-процессов (ReplBatch);
pro2cdc – для подключения CDC-процессов (CDCBatch);
Активация OpenEdge Change Data Capture
Теперь займемся включением самого механизма CDC, с помощью которого данные будут реплицироваться в дополнительную технологическую область. В каждую исходную базу данных Progress OpenEdge необходимо добавить отдельные области хранения, в которые будут дублироваться исходные данные, и активировать сам механизм с помощью команды proutil.
- Копируем из каталога C:\Pro2\db файл cdcadd.st в каталог исходной базы данных bisquit.
- Описываем в cdcadd.st экстенты фиксированного размера для областей «ReplCDCArea» и «ReplCDCArea_IDX». Добавлять новые области хранения можно в онлайне: prostrct addonline bisquit cdcadd.st
- Активируем OpenEdge CDC:
proutil bisquit -C enablecdc area «ReplCDCArea» indexarea «ReplCDCArea_IDX»
- В исходной базе данных необходимо создать следующих пользователей для идентификации работающих процессов:
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-процессов, она создается отдельно для каждого филиала.
- Распаковываем дистрибутив Pro2 в каталог /pro2
- Создаем и переходим в каталог /pro2/dbsh
- Создаем базу данных Schema Holder с помощью команды procopy $DLC/empty bisquitsh
- Выполняем конвертацию bisquitsh в необходимую кодировку — например в UTF-8 если базы данных Oracle имеют кодировку UTF-8: proutil bisquitsh -C convchar convert UTF-8
- После создания пустой базы данных bisquitsh подключаемся к ней в однопользовательском режиме: pro bisquitsh
- Переходим в Data Dictionary: Tools -> Data Dictionary -> DataServer -> ORACLE Utilities -> Create DataServer Schema
- Запускаем Schema Holder
- Настраиваем брокера 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- процессами. Первым делом настраиваем файлы параметров.
- Переходим в каталог C:\Pro2\bprepl\Scripts
- Открываем на редактирование файл replProc.pf
- Добавляем параметры подключения к репликационной базе данных cdc:
# Replication Database
-db cdc -ld repl -H <имя хоста основных БД> -S <порт брокера БД cdc>
-U pro2admin -P <пароль>
- Добавим в replProc.pf параметры подключения к исходным базам данных и Schema Holder в виде файлов параметров. Название файла параметров должно соответствовать названию подключаемой исходной базы данных.
# Connect to all replicated source BISQUIT
-pf bprepl\scripts\bisquit.pf
- Добавим в 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
- Сохраняем файл параметров replProc.pf
- Далее нужно создать и открыть на редактирование файлы параметров для каждой подключаемой исходной базы данных в каталоге C:\Pro2\bprepl\Scripts: bisquit.pf. В каждом pf -файле прописываются параметры подключения к соответствующей базе данных, например:
-db bisquit -ld bisquit -H <имя хоста> -S <порт брокера>
-U pro2admin -P <пароль>
Для настройки ярлыков Windows нужно перейти в каталог C:\Pro2\bprepl\Scripts и отредактировать ярлык «Pro2 – Administration». Для этого откроем свойства ярлыка и в строке Start in укажем инсталляционный каталог Pro2. Аналогичную операцию нужно проделать для ярлыков «Pro2 – Editor» и «RunBulkLoader».
Настройка Pro2 Administration: загрузка первичной конфигурации
Запускаем консоль.
![](https://habrastorage.org/getpro/habr/post_images/b82/639/717/b82639717e154bdb889038e56ca41d90.png)
Переходим в «DB Map».
![](https://habrastorage.org/getpro/habr/post_images/8ec/623/ae9/8ec623ae9f617ae630a42fa1d1b599c6.png)
Чтобы связать базы данных в Pro2 – Administration, переходим на вкладку DB Map. Добавляем маппинг исходных баз данных – Schema Holder – Oracle.
![](https://habrastorage.org/getpro/habr/post_images/d23/db6/d6c/d23db6d6c53ea7e7d47aa2b6a71b2cde.png)
Переходим на вкладку Mapping. В списке Source Database по умолчанию выбрана первая подключенная исходная база данных. Справа от списка должна быть надпись All Databases Connected — выбранные базы подключены. Ниже слева должен быть виден список таблиц Progress из bisquit. Справа — список таблиц из базы Oracle.
Создаем SQL-схемы и базы данных в Oracle
Для создания репликационной карты нужно сначала сгенерировать SQL-схему в Oracle. В Pro2 Administration выполняем пункт меню Tools -> Generate Code -> Target Schema, затем в диалоговом окне Select Database выделяем одну или несколько исходных баз данных и переносим их вправо.
![](https://habrastorage.org/getpro/habr/post_images/a15/d6b/ca5/a15d6bca502084aea7c24faace6494f3.png)
Нажимаем OK и выбираем каталог для сохранения SQL-схем.
Далее создаем базу. Это можно сделать, например, через Oracle SQL Developer. Для этого подключаемся к оракловой базе и загружаем схему для добавления таблиц. После изменения состава таблиц Oracle нужно обновить SQL-схемы в Schema Holder.
![](https://habrastorage.org/getpro/habr/post_images/a21/86f/d8d/a2186fd8d269e13120ce1ff2c87467d3.png)
После успешного завершения загрузки выходим из БД bisquitsh и открываем административную панель Pro2. На вкладке Mapping справа должны появиться таблицы из базы Oracle.
Маппинг таблиц
Для создания репликационной карты в административной панели Pro2 идем на вкладку Mapping, выбираем исходную базу данных. Кликаем по Map Tables, выделяем слева Select Changes таблицы, которые должны реплицироваться в Oracle, переносим их направо и подтверждаем выбор. Для выбранных таблиц карта будет создана автоматически. Повторяем операцию для создания репликационной карты для других исходных БД.
![](https://habrastorage.org/getpro/habr/post_images/455/9f9/1fe/4559f91fe85a7e724bf015f13873cbc3.png)
Генерация библиотеки процессора репликации 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. После завершения генерации программы появятся в каталоге bprepl\repl_mproc.
Настраиваем репликационные процессы в Pro2
Разделение таблиц на наборы, обслуживаемые отдельным потоком репликации, позволяет улучшить производительность и эффективность работы Pro2 Oracle. По умолчанию все создаваемые в репликационной карте связи для новых репликационных таблиц привязываются к потоку с номером 1. Рекомендуется разделять таблицы на разные потоки.
Информация о состоянии репликационных потоков отображается на экране Pro2 Administration во вкладке Monitor в секции Replication Status. Подробное описание значений параметров можно найти в документации Pro2 (каталог C:\Pro2\Docs).
Создаем и активируем политики CDC
Политики — это набор правил для механизма OpenEdge CDC, согласно которым выполняется отслеживание изменений в таблицах. На момент написания поста Pro2 поддерживает только политики CDC с уровнем 0, то есть отслеживается только факт изменения записи.
Для создания политики CDC на административной панели переходим на вкладку Mapping, выбираем исходную базу данных и щелкаем по кнопке Add/Remove Policies. В открывшемся окне Select Changes выбираем в левой части и переносим в правую таблицы, для которых необходимо создать или удалить политику CDC.
Для активации снова открываем вкладку Mapping, выбираем исходную базу данных и кликаем по кнопке (In)Activate Policies. Выделяем и переносим в правую часть таблицы, политики которых необходимо активировать, жмем OK. После этого они помечаются зеленым цветом. С помощью (In)Activate Policies также можно деактивировать политики CDC. Все операции выполняются онлайн.
![](https://habrastorage.org/getpro/habr/post_images/518/0ef/770/5180ef7709ef906a1541bb7e71b8b5ba.png)
После активации политики 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.
![](https://habrastorage.org/getpro/habr/post_images/f7f/e36/d10/f7fe36d10541f356f26d18f220a241cc.png)
Результаты
![](https://habrastorage.org/webt/96/tx/ic/96txicmq_eawginnc244qddkqww.png)
После внедрения у нас сильно ускорилась выгрузка информации в корпоративное хранилище данных. Данные самостоятельно попадают в Oracle в режиме онлайн. Не нужно тратить время на выполнение каких-то долгоиграющих запросов для сбора данных с разных систем. К тому же в этом решении процесс репликации умеет сжимать данные, что также положительно сказывается на скорости. Теперь ежедневная сверка системы БИСКВИТ с другими системами стала занимать 15-20 минут вместо 2-2,5 часов, а полная сверка — несколько часов вместо двух суток.
Комментарии (15)
Gostra
01.04.2019 19:32Делаете ли бекап базы Oracle?
Сложно ли будет после восстановления из бекапа «докатить» изменения?ryabtsevpv Автор
02.04.2019 12:24> Делаете ли бекап базы Oracle?
Да, обязательно.
> Сложно ли будет после восстановления из бекапа «докатить» изменения?
Нет. Наверное, штатный для админа СУБД функционал.
fessmage
02.04.2019 08:11Админил сервера бд для одной ИС на прогресс 10, тоже в банке, показалось страшным legacy из 90-х, плюс инструменты администрирования — сплошные костыли из скриптов на баше в 3 слоя. В остальном мире никто про такую базу и не слышал. Удивлен что кто-то ей пользуется добровольно, не планируя переезд.
Gostra
02.04.2019 10:37Добровольно пользуются некоторые, т.к. переезд на другую современную АБС стоит приличных денег, и в поддержании будет дороже…
Mazenrab
02.04.2019 12:35В остальном мире никто про такую базу и не слышал.
Ну неправда же. База конечно далеко не самая распространенная, но заграницей вполне себе известная.
В России в основном представлена в банковском секторе (БИСКВИТ), есть ряд торговых решений, мне известно о продукте медицинской направленности, ряд ERP-систем, используется вроде бы PepsiCo, концерном PSA (хотя это информация достаточно давняя, давно не слышал упоминаний). Хэдлайнер конечно думаю ВТБ )))
Не могу сказать что администрирование OE доставляет какую-то невероятную, несравнимую с другими БД боль. Мне кажется это дело привычки больше. К чему привык то и кажется более удобным. Хотя если нужен исключительно GUI для администрирования, то OE пока что по крайней точно не ваш выбор. Однако и в этом направлении делаются определенные шаги, с каждой версией OE Managment позволяет с помощью веб-интерфейса делать все больше и больше.fessmage
02.04.2019 12:53+1Я не столько имел ввиду Россию или зарубеж, сколько наслышанность о существовании этой СУБД в IT тусовке — никто еще ни разу из знакомых и коллег не говорил что слышал о ней, пользовался и знает что это такое. Каждый такой разговор я начинал с «звучит похоже на postgres, только progress». И ссылку обязательно на сайт как прув, иначе не верят.
ldmi
02.04.2019 15:09Администрю как раз и v10 — никаких костылей на баше не заметил.
fessmage
02.04.2019 15:33Повезло. Мне ИС досталась реализованная таким образом, что буквально всё, от авторизации и меню подключения пользователей к системе в режиме мульти-юзер до меню администрирования (с пунктами переключения after-image файлов, сохранения дампа, установки миграции) — было реализовано набором из нескольких десятков баш скриптов и файлов переменных. Одни скрипты рисовали cli меню, другие подключались при выборе пунктов, третьи реализовывали отдельные функции. Чтобы получить из этого мессива настоящее значение какого-либо параметра — приходилось собирать промежуточные значения через 3-5 слоев. А в конце это всё собиралось в команды для бинарников progress с установленными флагами и путями.
ldmi
02.04.2019 15:39А, это АБС была? Там (я, правда, давно видел) все так и сделано единым продуктом.
Я стандартными инструментами OpenEdge (Progress) пользуюсь. Есть конечно и свои скрипты, но не такие монстрообразные.
Ну и ПО у нас — GUI, а не терминальное.
ggo
02.04.2019 10:35что происходит с репликацией когда схема на источнике меняется?
ryabtsevpv Автор
02.04.2019 12:31Хороший вопрос. Думаю, что нужно сначала остановить процессы репликации, внести необходимые изменения в схеме источника, затем в оракл, обновить репликационную схему, запустить репликационные процессы.
Но, возможно не под все случаи этот вариант подойдет.
vgbash
02.04.2019 17:23В зависимости от того, что меняется. Если в реплицируемую таблицу будет добавлено новое поле, то репликация будет продолжаться без проблем, но и без нового поля пока не будет обновлена репликационная карта.
DmitriLevin
04.04.2019 11:47Добавление новых полей и таблиц не заставляет переделывать схему Оралка и Schema Holder. а вот удаление полей или таблиц — надо переделывать так как репликация останавливается когда не находит нужного поля или нужной
таблицы. У меня стоит pro2sql, но это то же самое что и pro2ora
У меня вопрос к автору: сколько данных перекачиваетсся из Прогресса в Оракл с помошю этого метода? Ведь вы тут пишите о колоссальный раметах. Сотни Террабайтах в год. Это здорово. Но хотелось бы понять реально сколько переходит через CDC в Оракл?
Gostra
Отлично!
Вопросы:
1) Сколько места занимает промежуточная база CDC? Она очищается по мере перезаливки данных в Оракл?
2) Схема в Oracle доступна всем только на чтение?
3) Какая средняя/максимальная между коммитом транзакции в Бисквите, и появлением изменений в Оракле?
4) Планируете научиться делать перезаливку напрямую в Оракл без промеждуточной таблицы?
5) Oracle partitioning использовать не планируете? Индексы по огромным таблицам signs, code в Оракле работают быстро?
ryabtsevpv Автор
Ответы:
1) В среднем объем промежуточной бд CDC порядка 5Gb. Да, данные в ней чистятся, как только они попадут в Оракловую базу.
Но как известно, физически объем экстентов меньше не станет.
2) Нет, есть пользователи с правами на запись.
3) Не замеряли. Интервал сна в процессах репликации можно регулировать от 1 секунды и более.
4) Первичная заливка делается напрямую, без промежуточной бд CDC.
5) В данном решении не используется, данных не так много.