даватися негайно, практично без затримок, у міру наповнення буфера журнальної інформації або в міру генерації нового журнального файлу (це встановлюється адміністратором). Пересилання даних по мірі генерації файлів абсолютно необтяжлива для робочої бази, так як цим займатиметься окремий процес-архіватор (ARCn). Незалежно від швидкості мережі, яка пов'язує обидва комп'ютера, або мережевий затримки, накопичена інформація буде передана.
2.4 Передача журнальних записів
Якщо виникне довготривалий збій мережі або комп'ютера з резервної базою даних, то журнали, що не були передані, будуть запитані резервною базою даних пізніше. У будь-якому випадку архіватор зберігає всю журнальну інформацію в каталозі на комп'ютері з робочою базою даних у вигляді файлів - веде архів журналів. Адміністратор зазвичай видаляє архів, коли в ньому відпала необхідність. Саме з цього архіву та будуть братися файли, які не вдалося передати в резервну базу. Для їх передачі примірник резервної бази створює процес FAL-клієнт, який звертається до примірника робочої бази. На ньому створюється процес, званий FAL-сервер, який і передає необхідну інформацію (рис. 3). У промислових системах, де навантаження на робочі бази даних велика, файли можна запитувати у інших резервних баз, які встигли вчасно отримати журнали. Традиційно ПО Oracle дає адміністраторам можливість налаштувати систему управління базами даних так, щоб задовольнити будь-які запити. Користуватися всіма можливостями відразу звичайно не потрібно. Достатньо знати, що такі можливості є і, якщо виникне необхідність, їх можна використовувати.
Рис. 3. Архітектура передачі журналів.
Архіватор зазвичай передає журнали з затримкою в десятки хвилин. Починаючи з версії Oracle9i, журнальну інформацію можна передавати без затримки за допомогою іншого процесу - записи в поточні журнальні файли (LGWR). При цьому резервна база даних може отримувати журнальну інформацію зі швидкістю її створення. Це дозволить у разі серйозного збою комп'ютера з робочою базою моментально активувати резервну (зробити її доступною для роботи користувачів), так як не доведеться чекати отримання найостанніших змін від основної бази. Щоб не виникало навантаження на робочу базу даних, мережеве з'єднання повинно бути досить швидким, тобто працювати з мінімальною затримкою, крім високої пропускної здатності каналу передачі.
При конфігуруванні процесу передачі журналів адміністратор також повинен вказати, чи необхідно основній базі даних призупиняти обслуговування користувачів доти, поки всі зміни не будуть передані в резервну базу. Якщо обслуговування не припиняти, то дані будуть передані процесами FAL із затримкою, коли відновиться мережеве з'єднання. При несприятливому збігу обставин: відмову мережі і наступному відмові робочої бази адміністратору потрібно буде дочекатися передачі відсутніх журналів і тільки тоді активувати резервну базу. Він може активувати резервну базу даних і негайно, але тоді частина змін буде втрачена. Їх потрібно буде вносити пізніше на логічному рівні. Залежно від важливості збережених даних адміністратор приймає рішення про рівень їх захисту.
2.5 Процеси Oracle Data Guard
Рішення про активацію резервної бази даних приймає адміністратор бази. Для полегшення процедури активації а...
