С 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). Итак, начнем.
Для работы 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 (repl) используется Pro2 для хранения конфигурационной информации, в том числе репликационной карты, названий реплицируемых баз данных и их таблиц. Здесь также содержится репликационная очередь, состоящая из заметок о факте изменения строки таблицы в исходной базе данных. Данные из репликационной очереди используются ETL-процессами для идентификации строк, которые необходимо скопировать в Oracle из исходной базы данных.
Cоздаем отдельную базу cdc.
Теперь займемся включением самого механизма CDC, с помощью которого данные будут реплицироваться в дополнительную технологическую область. В каждую исходную базу данных Progress OpenEdge необходимо добавить отдельные области хранения, в которые будут дублироваться исходные данные, и активировать сам механизм с помощью команды proutil.
Далее нам необходимо на сервере, где будут реплицироваться данные из СУБД Progress в СУБД Oracle, создать базу Sсhema Holder. DataServer Sсhema Holder – это пустая база данных Progress OpenEdge без пользователей или прикладных данных, содержащая карту соответствий исходных таблиц и внешних, оракловых таблиц.
База Schema Holder для Progress OpenEdge DataServer for Oracle для Pro2 должна располагаться на сервере ETL-процессов, она создается отдельно для каждого филиала.
С помощью административной панели Pro2 конфигурируются параметры Pro2, включая настройку репликационной схемы и генерацию программ ETL-процессов (Processor Library), программы первичной синхронизации (Bulk-Copy Processor), репликационные триггеры и политики OpenEdge CDC. Здесь также есть первичные средства мониторинга и управления ETL- и CDC- процессами. Первым делом настраиваем файлы параметров.
Для настройки ярлыков Windows нужно перейти в каталог C:\Pro2\bprepl\Scripts и отредактировать ярлык «Pro2 – Administration». Для этого откроем свойства ярлыка и в строке Start in укажем инсталляционный каталог Pro2. Аналогичную операцию нужно проделать для ярлыков «Pro2 – Editor» и «RunBulkLoader».
Запускаем консоль.
Переходим в «DB Map».
Чтобы связать базы данных в Pro2 – Administration, переходим на вкладку DB Map. Добавляем маппинг исходных баз данных – Schema Holder – Oracle.
Переходим на вкладку Mapping. В списке Source Database по умолчанию выбрана первая подключенная исходная база данных. Справа от списка должна быть надпись All Databases Connected — выбранные базы подключены. Ниже слева должен быть виден список таблиц Progress из bisquit. Справа — список таблиц из базы 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, переносим их направо и подтверждаем выбор. Для выбранных таблиц карта будет создана автоматически. Повторяем операцию для создания репликационной карты для других исходных БД.
Библиотека процессора репликации (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 Oracle. По умолчанию все создаваемые в репликационной карте связи для новых репликационных таблиц привязываются к потоку с номером 1. Рекомендуется разделять таблицы на разные потоки.
Информация о состоянии репликационных потоков отображается на экране Pro2 Administration во вкладке Monitor в секции Replication Status. Подробное описание значений параметров можно найти в документации Pro2 (каталог C:\Pro2\Docs).
Политики — это набор правил для механизма 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 часов, а полная сверка — несколько часов вместо двух суток.
Используя 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.
Порядок действий для создания базы
pro2adm – для подключения из административной панели Pro2;
pro2etl – для подключения ETL-процессов (ReplBatch);
pro2cdc – для подключения CDC-процессов (CDCBatch);
- На сервере баз данных создаем каталог для бд 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.
Порядок действий на примере для базы данных bisquit
- Копируем из каталога 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-процессов, она создается отдельно для каждого филиала.
Как создать Schema Holder
- Распаковываем дистрибутив 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: загрузка первичной конфигурации
Запускаем консоль.
Переходим в «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 часов, а полная сверка — несколько часов вместо двух суток.