Как подружить 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:\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.

    Порядок действий для создания базы
    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:\Pro2\db файл 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:\Pro2\bprepl\Scripts
    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 bprepl\scripts\bisquit.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:\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: загрузка первичной конфигурации


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



    Переходим в «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. После завершения генерации программы появятся в каталоге 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. Все операции выполняются онлайн.



    После активации политики 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 часов, а полная сверка — несколько часов вместо двух суток.
    ВТБ
    96,69
    Компания
    Поделиться публикацией

    Комментарии 16

      0
      Отлично!
      Вопросы:
      1) Сколько места занимает промежуточная база CDC? Она очищается по мере перезаливки данных в Оракл?
      2) Схема в Oracle доступна всем только на чтение?
      3) Какая средняя/максимальная между коммитом транзакции в Бисквите, и появлением изменений в Оракле?
      4) Планируете научиться делать перезаливку напрямую в Оракл без промеждуточной таблицы?
      5) Oracle partitioning использовать не планируете? Индексы по огромным таблицам signs, code в Оракле работают быстро?
        +2
        Ответы:
        1) В среднем объем промежуточной бд CDC порядка 5Gb. Да, данные в ней чистятся, как только они попадут в Оракловую базу.
        Но как известно, физически объем экстентов меньше не станет.
        2) Нет, есть пользователи с правами на запись.
        3) Не замеряли. Интервал сна в процессах репликации можно регулировать от 1 секунды и более.
        4) Первичная заливка делается напрямую, без промежуточной бд CDC.
        5) В данном решении не используется, данных не так много.
        0
        Делаете ли бекап базы Oracle?
        Сложно ли будет после восстановления из бекапа «докатить» изменения?
          +2
          > Делаете ли бекап базы Oracle?
          Да, обязательно.
          > Сложно ли будет после восстановления из бекапа «докатить» изменения?
          Нет. Наверное, штатный для админа СУБД функционал.
          0

          Админил сервера бд для одной ИС на прогресс 10, тоже в банке, показалось страшным legacy из 90-х, плюс инструменты администрирования — сплошные костыли из скриптов на баше в 3 слоя. В остальном мире никто про такую базу и не слышал. Удивлен что кто-то ей пользуется добровольно, не планируя переезд.

            0
            Добровольно пользуются некоторые, т.к. переезд на другую современную АБС стоит приличных денег, и в поддержании будет дороже…
              +1
              В остальном мире никто про такую базу и не слышал.

              Ну неправда же. База конечно далеко не самая распространенная, но заграницей вполне себе известная.

              В России в основном представлена в банковском секторе (БИСКВИТ), есть ряд торговых решений, мне известно о продукте медицинской направленности, ряд ERP-систем, используется вроде бы PepsiCo, концерном PSA (хотя это информация достаточно давняя, давно не слышал упоминаний). Хэдлайнер конечно думаю ВТБ )))

              Не могу сказать что администрирование OE доставляет какую-то невероятную, несравнимую с другими БД боль. Мне кажется это дело привычки больше. К чему привык то и кажется более удобным. Хотя если нужен исключительно GUI для администрирования, то OE пока что по крайней точно не ваш выбор. Однако и в этом направлении делаются определенные шаги, с каждой версией OE Managment позволяет с помощью веб-интерфейса делать все больше и больше.
                +1
                Я не столько имел ввиду Россию или зарубеж, сколько наслышанность о существовании этой СУБД в IT тусовке — никто еще ни разу из знакомых и коллег не говорил что слышал о ней, пользовался и знает что это такое. Каждый такой разговор я начинал с «звучит похоже на postgres, только progress». И ссылку обязательно на сайт как прув, иначе не верят.
                0
                Администрю как раз и v10 — никаких костылей на баше не заметил.
                  0
                  Повезло. Мне ИС досталась реализованная таким образом, что буквально всё, от авторизации и меню подключения пользователей к системе в режиме мульти-юзер до меню администрирования (с пунктами переключения after-image файлов, сохранения дампа, установки миграции) — было реализовано набором из нескольких десятков баш скриптов и файлов переменных. Одни скрипты рисовали cli меню, другие подключались при выборе пунктов, третьи реализовывали отдельные функции. Чтобы получить из этого мессива настоящее значение какого-либо параметра — приходилось собирать промежуточные значения через 3-5 слоев. А в конце это всё собиралось в команды для бинарников progress с установленными флагами и путями.
                    0
                    А, это АБС была? Там (я, правда, давно видел) все так и сделано единым продуктом.
                    Я стандартными инструментами OpenEdge (Progress) пользуюсь. Есть конечно и свои скрипты, но не такие монстрообразные.
                    Ну и ПО у нас — GUI, а не терминальное.
                0
                что происходит с репликацией когда схема на источнике меняется?
                  +2
                  Хороший вопрос. Думаю, что нужно сначала остановить процессы репликации, внести необходимые изменения в схеме источника, затем в оракл, обновить репликационную схему, запустить репликационные процессы.
                  Но, возможно не под все случаи этот вариант подойдет.
                    0
                    В зависимости от того, что меняется. Если в реплицируемую таблицу будет добавлено новое поле, то репликация будет продолжаться без проблем, но и без нового поля пока не будет обновлена репликационная карта.
                    0
                    Добавление новых полей и таблиц не заставляет переделывать схему Оралка и Schema Holder. а вот удаление полей или таблиц — надо переделывать так как репликация останавливается когда не находит нужного поля или нужной
                    таблицы. У меня стоит pro2sql, но это то же самое что и pro2ora

                    У меня вопрос к автору: сколько данных перекачиваетсся из Прогресса в Оракл с помошю этого метода? Ведь вы тут пишите о колоссальный раметах. Сотни Террабайтах в год. Это здорово. Но хотелось бы понять реально сколько переходит через CDC в Оракл?
                      0
                      На данный момент в Оракле 6TB прогрессовых данных, но в ближайшем будущем планируется настройка репликации и на других базах, объемы будут расти.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое