До вашої уваги – матеріал про наш корисний досвід використання 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]
