Потоци от данни в Oracle - всичко за ИТ и програмиране

Написано на 26 декември 2008 г. Публикувано в Oracle

СЪДЪРЖАНИЕ

Потоците от данни се появиха във версия 9 на Oracle, а във версия 10 те се развиха във възможностите (например Down Stream) и в организацията (например пул от потоци на собствен източник на памет).

За разлика от "нормалната" репликация, Oracle Streams не изисква създаването на специални структури в базата данни (дневници на таблици, материализирани изгледи). Подобно на механизма за репликация, използван отдавна в Sybase, репликацията в Oracle Streams се основава на обработка на информация от регистрационния файл на базата данни.

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

Основните елементи, включени в потока на данни, са:

Процесът на улавяне. Фонов процес, който постоянно сканира работещи и архивирани журнали с помощта на LogMiner; избира от тях необходимите записи за промени в изходната таблица/схема/DB (INSERT, UPDATE, DELETE, MERGE, актуализации на LOB поле); генерира от тези записи запис за логическа промяна, Запис за логическа промяна (LCR); поставя LCR като събитие в опашка на Streams Advanced Queuing (SAQ).
Процесът на размножаване. Постоянно избира събития от опашката в изходната база данни и ги прехвърля към опашките на получаващите бази данни чрез Oracle Net.
Процесът на извършване, прилагане на промени (Apply Process). Непрекъснато извлича събития от опашка в получаващата СУБД. LCR се прилагат директно към таблиците на получаващата база данни или се прехвърлят към програма за обработка, написана от потребителя по негова преценка.
Опашка Може да бъде съставен от подреден набор (списък) от обекти от определен тип, но по-често се използват опашки от обекти от типа SYS.ANYDATA. Опашката получава LCR (автоматично, вспоред зададените правила или изрично добавени от програмата) или по-общи съобщения (вмъкват се и се извличат ръчно). Опашката се моделира с помощта на специално създадени сервизни таблици, но за автоматично поставени в опашка LCR събития има допълнителен буфер в SGA.

СУБД и конфигурация на база данни за възможност за организиране на нишки

Опции за СУБД> За да организирате потоците от данни, трябва да имате правилните стойности за редица параметри на СУБД, но най-често е достатъчно да се уверите в следното:

СЪВМЕСТИМ >= 9.2 Следното предполага >= 10.1.0.

GLOBAL_NAMES = TRUE за всяка база данни, участваща в трансфера на данни.

Параметърът съществува от версия 10.1 и указва областта на паметта за временно поставяне на заснети събития. Ако STREAMS_POOL_SIZE = 0, ще се използва памет от споделения пул, до 10% от тази област.

Когато изчислявате, вземете предвид следното: + 10m за всяко ново ниво на паралелност на процеса на улавяне + 1m за всяка степен на паралелност на процеса на приложение + 10m за всяка нова опашка от уловени събития.

Във версия 9.2 тежестта за разпределяне на паметта за нуждите на нишките пада върху споделения пул.

SHARED_POOL_SIZE Всеки процес на заснемане изисква 10M споделена пул памет за буфер на опашка; в същото време всички нужди на споделения пул на Oracle Streams не могат да заемат повече от 10% от тази област.

SGA_MAX_SIZE (Ако е включена версия 10). Стойността трябва да вземе предвид нуждите на SGA частите (вижте по-горе), особено за извършване на улавяне на промени с LogMiner. Примерът по-долу, поради своята простота, работи дори при SGA_MAX_SIZE = 400m.

Конфигурация на база данни

База данни, която поддържа процеса на улавяне на промените, трябваработа в режим на архивиране.

База данни, която поддържа процеса на улавяне на промените, трябва да осигури допълнително регистриране на ниво отделни таблици или цялата база данни. В този режим промените в таблицата се регистрират в разширен формат, включително стари и нови стойности на полета (независимо кои полета действително са променени), така че процесът на прилагане на промени в получаващата СУБД да може недвусмислено да възпроизведе промяната.

Разширеното регистриране може да бъде активирано не непременно за цялата база данни, но е достатъчно за репликирани таблици. Стойността на колона в таблицата на базата данни източник трябва безусловно (ВИНАГИ, безусловно) да се регистрира, ако съответната колона в таблицата на базата данни местоназначение:

индексиран (поне поради съществуващото ограничение за целостта)
участва в правило за трансформиране на данни или се обработва от манипулатор

Както изходната база данни, така и целевата база данни използват работни таблици за съхраняване на данни от опашка и други нужди. За тяхното разположение е препоръчително да се отделят отделни таблични пространства. В изходната база данни е желателно да присвоите таблично пространство, различно от SYSTEM, към процеса на LogMiner.

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

Технологично организацията на потоците се осъществява чрез използването на редица вградени пакети от схемата SYS:

Пример за изграждане на поток за промяна В този пример базата данни източник на поток е наречена MAINDB.CLASS, а базата данни местоназначение на потока е наречена SUBDB1.CLASS. Мрежови имена на бази в Oracle Net съответно SOURCE и DESTINATION. Предполага се, че и двете бази данни имат схема SCOTT.

Примерът е за версия 10.2. Предполага се, че командите се издават в SQL*Plus.

Подготовка

Нека преведем изходната база данни врежим на архивиране на лог файл:

Нека създадем работещи таблични пространства в двете бази данни, например:

Във версия 9.2 в изходната база данни е желателно да се присвои таблично пространство, различно от SYSTEM, към процеса на LogMiner (във версия 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 се прилагат в получаващата база данни в рамките на една (автономна) транзакция (независимо от факта, че в регистрационния файл на базата данни множество промени се извършват от набор от промени на един ред). Следователно грешка дори при промяна на единичен ред ще доведе до неуспех на промените в цялата множествена операция.