бо її автоматизації, починаючи з версії Oracle9i, в Data Guard можна використовувати додаткові процеси, звані Data Guard Broker (dgbroker) і Data Guard Monitor (DMON). Вони запускаються на примірниках робочої і резервних баз і автоматизують процеси активації резервної бази, передачі відсутніх журналів і перезапуску примірників, де стався збій. Ці процеси можуть бути запущені на будь-якому з примірників, обслуговуючих бази даних. Архітектура роботи цих процесів схожа з менеджером процесів OPMN і DMON, які використовуються в сервері додатків Oracle9i AS. Процес DMON використовує власний файл, де зберігає корисну для себе інформацію, яку небажано втрачати при зупинці примірника (наприклад, відомості про те, які бази в мережі основні, а які - резервні). Наприклад, у випадку зупинки основної бази і подальшого монтування процеси автоматично відкриють основну базу. Якщо адміністратор передбачає виконати якісь дії в режимі монтування, вони швидше за все будуть виконуватися на відкритій базі. Позитивна риса цих процесів в тому, що їх можна безбоязно відключити в будь-який момент навіть без зупинки екземпляра. Оболонки адміністрування Data Guard вимагають їх роботи і при необхідності запускають процеси.
Адміністратори часто стикаються з тим, що в базу внесено помилкові зміни і необхідно відновити дані на певний момент часу в минулому. У СУБД Oracle передбачена можливість вказати в запиті час, на який потрібні дані. Ця можливість з'явилася у версії 9i і називається Oracle Flashback. Однак якщо таблиця з даними видалена повністю, то скористатися цією можливістю не можна. Для таких випадків адміністратор може вказати для однієї з резервних баз даних затримку, з якою потрібно вносити в неї зміни з отриманих журналів (рис. 4).
Рис. 4. Резервна база з відставанням за часом.
2.6 Логічна резервна база
У процесі роботи резервна база даних не може обслуговувати користувачів. Проте бажання включити її в повсякденну роботу залишається. Резервна база може обслуговувати запити користувачів в ті моменти, коли вона не вносить у свої файли змін. При цьому журнальні файли будуть накопичуватися на комп'ютері з резервною базою, і їх можна буде ввести в файли пізніше. Наприклад, вдень резервна база може бути відкрита для читання і обслуговувати запити, для яких актуальність інформації не важлива. Це можуть бути додатки, що обробляють дані за минулі дні, - наприклад, системи підтримки прийняття рішень (decision support system), які створюють велике навантаження на робочу базу даних. При цьому резервна база даних буде приймати всі журнали, згенеровані робочою базою протягом дня. На ніч же адміністратор може перевести резервну базу даних в режим внесення накопичених змін.
Як альтернативу можна використовувати логічну резервну базу даних. Така можливість з'явилася у версії Oracle 9.2, і її можна використовувати одночасно з традиційними фізичними резервними базами. Адміністратор сам вибирає, скільки і яких резервних баз повинно бути. Журнальна інформація містить всі відомості про те, які зміни були внесені в робочу базу даних. У версії 8i з'явилася можливість аналізувати журнальні файли і відтворювати частина команд, які виконувалися користувачами при роботі з основною базою даних. Допрацювавши цю технологію і домігшись відновлення більшої частини команд, компанія Oracle змогла запропонувати нову...
