Потоки даних у Oracle – це дуже просто

Знає назву потоку лише той, хто поблизу мешкає Теогонія, Гесіод

Від Махачкали до Баку Місяця плавають на боці, І, хитаючись, пливуть вали Від Баку до Махачкали. Качка в Каспійському морі, Вірші Б. Корнілова, музика Ю. Візбора

Зміст

Потоки даних у Oracle – пізніша, ніж «звичайна» реплікація (одностороння, двостороння і багатостороння), модель організації безперервного перенесення даних як усередині БД, так і між базами. На відміну від «звичайної» реплікації Oracle Streams не вимагає закладу особливих структур у БД (журналів таблиць та materialized views), але переносить дані, почерпнуті з журналу БД. У статті розглядається приклад побудови перенесення даних засобами Oracle Streams між двома базами.

widom/stream.ppt: зокрема, реалізація Oracle Streams не пропонує мовного оформлення, а лише на рівні API. Технічно потоки Oracle Streams спираються на створений незалежно і раніше апарат організації черг передачі повідомлень відомий під назвою Oracle Advanced Queuing.

Потоки даних з'явилися в Oracle версії 9, а версії 10 отримали свій розвиток у можливостях (наприклад, Down Stream) і в організації (наприклад, власне джерело пам'яті streams pool).

На відміну від «звичайної» реплікації Oracle Streams вимагає закладу спеціальних структур у БД (журналів таблиць, materialized views). Подібно до механізму реплікації, що давно використовувався в Sybase, реплікація в Oracle Streams заснована на обробціінформації із журналу БД.

Основні поняття

У потоковій передачі даних беруть участь такі основні елементи:

Процес захоплення змін(Capture Process). Фоновий процес, що постійно переглядає засобами LogMiner робочі та архівовані журнали; вибирає їх необхідні записи про зміни у вихідної таблиці/схеме/БД (INSERT, UPDATE, DELETE, MERGE, оновлення полів LOB); формує з цих записівлогічний запис про зміну, Logical Change Record (LCR); поміщає LCR якподію в чергу, сформовану засобами Streams Advanced Queuing (SAQ)(до версії 10 використовувалася назва Advanced Queuing (AQ)).
Процес передачі змін(Propagation Process). Постійно вибирає події з черги у вихідній БД і передає їх у черги приймаючих БД через Oracle Net.
Процес внесення, застосування змін(Apply Process). Постійно обирає події з черги до приймаючої СУБД. LCR або застосовуються безпосередньо до таблиць приймаючої БД, або передаються програмі обробки, написаної користувачем на власний розсуд.
Черга(queue). Вона може складатися з упорядкованої множини (списку) об'єктів конкретного типу, але частіше використовуються черги з об'єктів типу SYS.ANYDATA. У чергу потрапляють LCR (автоматично, відповідно до заданих правил, або явним додаванням з програми) або більш загальні повідомлення (вставляються та витягуються вручну). Черга моделюється за допомогою спеціально створюваних службових таблиць, але для подій LCR, що автоматично розміщуються в черзі, додатково є буфер в SGA.

Конфігурація СУБД та БД для можливості організації потоків

Параметри СУБД

Для організації потоків даних потрібно матиналежні значення цілого ряду параметрів СУБД, проте найчастіше достатньо впевнитись у наступному:

При розрахунку слід враховувати наступне: + 10m для кожного нового рівня паралелізму процесу захоплення + 1m для кожного ступеня паралелізму процесу застосування + 10m для кожної нової черги захоплених подій

У версії 9.2 навантаження виділення пам'яті під потреби потоків лягає на shared pool.

SHARED_POOL_SIZEКожен процес захоплення вимагає 10M у пам'яті shared pool для буфера черги; в той же час, всі потреби Oracle Streams у shared pool не можуть займати більше 10% цієї області.

SGA_MAX_SIZE(Якщо йдеться про версію 10). Значення повинно враховувати потреби частин SGA (див. вище), особливо для захоплення змін за допомогою LogMiner. Приклад, наведений нижче, з його простоти працює навіть за значення SGA_MAX_SIZE = 400m.

Конфігурація БД

БД, що підтримує процес захоплення змін, має працювати у режимі архівування.

БД, підтримує процес захоплення змін, має забезпечити лише на рівні окремих таблиць чи всієї БД режим розширеної журналізації (supplemental logging). У цьому режимі журнальні записи про зміни в таблицях заносяться в розширеному форматі, включаючи дані старих і нових значень полів (незалежно від того, які поля фактично змінювалися) для того, щоб процес застосування зміни приймаючої СУБД зміг однозначно відтворити зміну.

Розширену журналізацію можна включати не обов'язково для всієї БД, але достатньо для таблиць, що реплікуються. Значення стовпця у таблиці вихідної БД має безумовно (ALWAYS,unconditionally) потрапляти до журналу, якщо відповідний стовпець у таблиці приймаючої БД:

індексований (хоча бвнаслідок наявного обмеження цілісності)
бере участь у правилі перетворення даних або обробляється програмою обробки (handler)

Як БД-джерело, так і БД-одержувач використовують робочі таблиці для зберігання даних черг та інших потреб. Для їхнього розміщення доцільно виділити окремі табличні простори. У БД-джерелі бажано призначити процесу LogMiner табличний простір, інший, ніж SYSTEM.

Системні пакети

Технологічно організація потоків здійснюється через вживання ряду вбудованих пакетів із схеми SYS:

Приклад побудови потоку змін

У цьому прикладі БД-джерело потоку має ім'я MAINDB.CLASS, БД-приймач потоку носить ім'я SUBDB1.CLASS. Мережеві імена баз у Oracle Net відповідно SOURCE та DESTINATION. Передбачається, що обох БД є схема SCOTT.

Приклад для версії 10.2. Передбачається, що команди видаються SQL*Plus.

Підготовка

Перекладемо БД-джерело в режим архівування журнальних файлів:

Створимо робочі табличні простори в обох БД, наприклад:

У версії 9.2 у БД-джерелі бажано призначити процесу LogMiner табличний простір, інший, ніж SYSTEM (у версія 10 воно вже SYSAUX), наприклад:

В обох базах створимо адміністратора потоків:

Повторіть ті ж дії для SUBDB1.CLASS.

У БД-джерелі заведемо зв'язок із БД-одержувачем. Оскільки БД-одержувач називається глобально, ім'я зв'язку має збігатися з цим світовим ім'ям:

Формування потоків

Створимо чергу для передачі подій у БД-джерелі та чергу для застосування подій у БД-одержувачі, наприклад:

Коли зазначено спеціально, черги в обох БД (і таблиці для цих черг) отримали умовні назви.Їх можна спостерігати так:

Черга AQ$_*_E створюється автоматично для повідомлень про помилки обробки подій.

Для можливості передавати потоком зміни у вихідній таблиці SCOTT.EMP потрібно заявити розширену журналізацію хоча б цієї таблиці:

Тепер виправлення будь-якого поля в таблиці EMP супроводжуватиметься (безумовно) занесенням до журналу не лише старого та нового значень цього поля, але й значення ключового поля (тобто EMPNO).

У БД-джерелі створимо процес захоплення змін, одночасно вказавши правила відбору змін у чергу:

Серед інших умовчань при створенні процесу захоплення змін вище використане мовчазне ім'я черги STREAMS_QUEUE. У нашому випадку це можна було б визначити явно, вказавши параметр QUEUE_NAME => 'streamadmin.streams_queue'. Цим же параметром можна скористатися, коли процес захоплення потрібно буде зв'язати з чергою під іншим ім'ям.

Правила відбору змін у чергу STREAMS_QUEUE також були побудовані автоматично, але могли бути доповнені, або навіть виписані явно за допомогою інших параметрів процедури ADD_TABLE_RULES.

Створимо процес перенесення змін:

Тепер для правильного відтворення змін у приймаючій БД потрібно передати їй як «точку відліку» номер змін у БД-джерелі. Передаватися одержувачам будуть лише зміни в EMP з пізнішими номерами:

Переконатися в обліку процесом застосування таблиць точки відліку можна запитом:

БД, що приймає, готова до активації процесу застосування змін:

Для зручності відключимо реакцію на помилки, інакше процес застосування змін може мимоволі припинятися:

Залишилося запустити процеси захоплення та застосування змін:

Зауважте, щопотік переносить зміни лише в один бік. Таблиця-приймач при цьому не закрита від звичайної редагування. Однак таку правку слід виконувати обачно, оскільки вона може призвести до помилок при автоматичній зміні даних потоком (ця проблема вирішується спеціально засобами вирішення конфліктів). Крім того, врахуйте, що численні операції INSERT, UPDATE, DELETE використовуються в приймаючій БД в рамках однієї (автономної) транзакції (незважаючи на те, що в журналі БД численні зміни фіксуються набором однорядкових змін). Отже, помилка хоча б у зміні одного-єдиного рядка призведе до відмови змін всієї множинної операції.

Вправа. Внести зміни до таблиці SCOTT.EMP на приймаючій БД. Переконатися в розбіжностях, що зберігаються, в таблицях БД-джерела та БД-отримувача.

Вправа. Перевірити передачу змін DDL. Додати стовпець до таблиці [email protected]. Спостерігати результат у [email protected]. Змінити тип стовпця, спостерігати результат у базі-одержувачі.

додаткова інформація

За додатковою інформацією звертайтесь до компанії Interface Ltd.