У даній статті ми розглянемо основні питання пов'язані з використанням резервної БД Oracle. Перш за все відповімо на питання - навіщо потрібна резервна БД? Її основне призначення - оперативно відновити основну, також звану первинної, БД з мінімальними втратами інформації. Переключити резервну БД в режим основної - це справа кількох хвилин при відповідній організації процесів адміністрування баз даних.
Для надійності сервера і пристрої зберігання даних первинної та резервної баз даних слід рознести в фізично ізольовані приміщення компанії, і, навіть будівлі настільки, наскільки дозволяє мережу компанії. В цьому випадку ми зможемо уникнути непоправних втрат навіть у випадках таких фатальних подій, як пожежі та теракти.
Створення резервної БД має сенс для динамічної БД знаходиться в режимі ARCHIVELOG, і для примірники якої або запущені або створюються при необхідності процеси архівування журнальних файлів БД. Тобто і БД та екземпляр знаходяться в режимі ARCHIVELOG.
Це найпростіший варіант створення фізичної резервної БД. Можна також створити логічну резервну БД, в тому числі крос-платформену. Але процес відновлення логічної БД набагато більш трудомісткий, так як зміни в БД здійснюються не оновленням блоків даних, а шляхом трансформації змін в SQL запити і виконання цих запитів.
Отже, ми розробили архітектуру резервного сервера і встановили необхідне програмне забезпечення, в тому числі шляхом простого перенесення файлів. Тепер для створення резерной БД потрібно виконати просту процедуру. Зупинимо екземпляр Oracle за допомогою команди SQL * Plus shutdown або shutdown immediate. На короткий час піднімемо екземпляр і створимо резервний контрольний файл.
> Alter database mount;
> Alter database create standby controlfile as 'c: \ control.stb';
Тепер зупинимося на питаннях управління резервної БД.
Резервна БД повинна бути активована. Для цього з копій основний БД видалимо контрольні файли, помістимо на їх місця створений резервний контрольний файл, виконаємо відповідні зміни в файлі ініціалізації параметрів. Відредагуємо при необхідності інші параметри.
Запустимо прослуховувач Oracle. За допомогою утиліти oradim.exe при необхідності створимо службу, і запустимо цю службу за допомогою цієї ж утиліти. Зауважимо, що параметри зазначеної утиліти для різних версій Oracle різняться, тому спочатку має сенс запустити її з питанням - oradim.exe /.
Запускаємо командну оболонку SQL * Plus за допомогою комади sqlplus.exe / nolog. Залежно від ОС нам може знадобитися або ж немає команда SQL * Plus startup nomount. У разі чого оболонка SQL * Plus проінформує про те, що екземпляр вже запущений. Далі ми монтуємо резерную БД, приблизно такими директивами:
SQL> CONNECT sys / sys_pwd @ standby1 AS SYSDBA
SQL> STARTUP NOMOUNT pfile = / oracle / admin / pfile / initSTBY.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
Якщо все зроблено належним чином, то наша резервна БД готова до використання. Вона може функціонувати в 3 основних режимах (mode):
- Managed recovery mode
- Manual recovery mode
- Read-only mode
У керованому режимі (Managed recovery mode), який правильніше назвати автоматичним, основний сервер передає через прослуховувач резервного сервера архівні журнальні файли на резервний сервер у відповідні каталоги, а резервний сервер їх автоматично застосовує. У версії Oracle9i ця процедура була гордо названа Data Guar. Ви можете з нею ознайомитися з відповідною технологією за наступним посиланням. Однак використовувати цю технологію я не рекомендую. Можливо процедура автоматичної передачі файлів безумовно корисна, але наскільки на ефективніше процедур передачі файлів, таких як cp або rcp на unix системах? Але для використання зазначеного режиму є більш відчутні перешкоди.
Наступний аргумент полягає в тому, що резерную БД слід контролювати на працездатність. Для цього її треба переводити в режим доступності читання з БД (Read-only mode). В цьому режимі відновлення не можливо, тому за цей час виникають пропуски в послідовності архівних журнальних файлів, і для відновлення послідовності, а відповідно можливості автоматичного режиму, необхідно застосовувати ручний режим. Якщо БД динамічна, журнальні файли короткі, то відновити автоматичний режим стане важко.
Тому ми вибираємо ручний режим, і доповнюємо його засобами автоматизації. В ручному режимі для відновлення Бд потрібно скопіювати чергову порцію архівних журнальних файлів в каталог, що задається змінною LOG_ARCHIVE_DEST_n (n ціле від 1 до 5), або змінною LOG_ARCHIVE_DEST, і запустити відновлення з опцією AUTOMATIC
SQL> RECOVER AUTOMATIC STANDBY DATABASE
Після застосування придатних файло Oracle покаже ім'я журналу, який в каталозі відсутній, наприклад, ви можете побачити такі повідомлення SQL * Plus:
ORA-00308: can not open archived log '/oracle/standby/standby_logs/arcr_1_540.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Ви вибираєте опцію CANCEL - і завершуєте процес відновлення.
Media recovery cancelled.
Якщо ми помістили файли в інший каталог, то можна використовувати команду RECOVER AUTOMATIC STANDBY DATABASE з опцією FROM 'путь_к_каталогу_с_файламі_журнала', напрмер
SQL> RECOVER FROM '/ logs' STANDBY DATABASE;
У режимі читання з резервної БД для многоих запитів можуть знадобитися сортування, коіторие зажадають дискових операцій. Тому, можливо, буде потрібно створення тимчасового табличного простпанства з тимчасовим файлом
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> ALTER DATABASE OPEN READ ONLY;
SQL> CREATE TEMPORARY TABLESPACE tbs_1 TEMPFILE 'file_1.f' EXTENT MANAGEMENT LOCAL UNIFORM SIZE 2048M;
При перекладі БД в режим standby під Oracle 9.2 проявилася наступна дратує помилка
SGA initialization / DB open not complete even after 5 minutes, QMN0exiting
error 604 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00604: error occurred at recursive SQL level 1
ORA-01219: database not open: queries allowed on fixed tables / views only
Dump file f: \ database \ bdump \ bv_qmn0_хххх.trc
Вона не позначалася на функціональності. Резервна БД акуратно застосовувала архіви журналів. Але плодилися файли дампов і не покидало почуття незадоволеності виконаною роботою. Причина виявилася легко усуненою. Параметр примірника aq_tm_process не була дорівнює 0 і екземпляр безуспішно намагався запустити відповідні qmno процеси, які вимагають, щоб БД була відкрита. Вирішити завдання виявилося дуже ппросто, приблизно так
alter system set aq_tm_processes = 0 scope = both;
Але ми повинні розуміти, що тим Сасма ми ще більше віддаляємося від робочого примірника. І при активації резервної БД слід повернути первісне значення всім зміненим параметрам.