Реплікація в Oracle, Mystic s Blog

Реплікація в Oracle

  • Oracle DB 11g - 2 штуки (головна "MASTER_DB" і дочірня "SLAVE11")
  • Oracle DB 10g R2 - 1 штука (дочірня "SLAVE10")

У всіх базах є користувач ANALYTICS із таблицею TT2.

Завдання: настроїти автоматичне оновлення даних у головній базі при внесенні змін до дочірніх.

Для реплікації використовуватимемо потоки даних (Oracle Streams). Суть технології така:

у основі створюються т.зв. черги повідомлень (queues) та процеси запису, передачі та зчитування даних із цих черг (Capture, Propagation та Apply відповідно). Вся ця взаємодія називається Oracle Stream. Фізично черги повідомлень - це записи у відповідній таблиці черг.

Процес Capture стежить за оновленнями архівного журналу БД (archive log) і зчитує всі оновлення, що стосуються зазначеної таблиці/табличного простору/схеми/всієї бази. Таким чином, процес не заважає звичайним транзакціям. Але при цьому БД має працювати у режимі ведення журналу ARCHIVELOG.

У Enterprise Manager'і є візард створення реплікації, але мені не вдалося змусити його зробити хоч щось інше, тому діємо в основному через консоль

1. Перевіряємо, чи база в режимі ведення журналу через Enterprise Manager

Availability-> Recovery Settings

через консоль включаємо так:

2. Всі потоки будуть розміщені в окремій схемі адміністратора потоків (Streams Admininstator). Створюємо схему та користувача strmadmin у всіх базах. Детальний мануал з картинками з документації до 11g Обов'язково даємо йому роль DBA і додатково під користувачем з DBA виконуємо наступний код:

3. Створюємо чергу. Заходимо під strmadmin (всі подальші дії у всіх базахтеж від імені strmadmin) і в кожній базі виконуємо:

Коротко - процедура створює таблицю з ім'ям STREAMS_QUEUE_TABLE і чергу STREAMS_QUEUE . У дочірніх БД записуватимемо зміни в цю чергу, а в головній — зчитуватимемо з неї. 4. Для передачі з однієї бази в іншу, використовується DB Link, причому з боку дочірньої бази. Створюємо ДБлінк до головної бази

У параметрах лісенера дочірніх баз має бути прописане з'єднання «MASTER_DB» із головною базою.

5. Під strmadmin'ом у SLAVE11 створюємо процес передачі даних (propagation) з черги до дочірньої в чергу в головній базі

streams_name — довільна назва потоку передачі даних

source_queue_name - ім'я черги з якої беруться дані destination_queue_name - ім'я черги на головній базі, куди все передається. Обов'язково із зазначенням ДБлінку

6. Налаштовуємо процес збирання змін у SLAVE11 під strmadmin (capture)

queue_name - назва черги, в яку записуються зміни

7. Не дуже зрозуміла процедура, яка робить тип зліпок з поточного стану таблиць в обох базах і встановлює які зміни будуть реплікуватися, а які ні. Виконується у SLAVE11 (дочірній базі)

8. У MASTER_DB, під strmadmin включаємо процес зчитування та запису змін (apply)

9. Запускаємо процеси зчитування та запису у базі MASTER_DB

Така реплікація відстежуватиме DDL та DML зміни таблиці.