dest
SQL> startup mount;> recover database until cancel using backup controlfile;
На запит імені архівного журналу ввести AUTO або повний шлях до файлу. Після того, як всі журнальні файли застосуються, відкрити базу даних з опцією resetlogs
SQL> alter database open resetlogs;
Глава 5. Резервування та відновлення
Можливий повний відмова систем, файли можуть помилково віддалятися, можуть відбуватися збої носія. АБД, у якого немає обгрунтованої стратегії резервування і відновлення для вирішення таких ситуацій, повинен мати під рукою своє резюме про надходження на роботу.
У будь-якого бізнесу повинна бути стратегія відновлення після катастроф, які призводять до втрати даних. В даний час тільки 45% компаній зі списку найбільших компаній світу мають формальні стратегії для свого захисту від тяжкої втрати даних. Тільки 12% з цих стратегій розглядаються на корпоративному рівні («Calculating the Cost of Downtime» (обчислення вартості часу простою)). При розробці формальної стратегії АБД повинні планувати втрату даних через несподівані відмов, причинами яких можуть бути апаратні чи програмні збої, людські помилки, природні явища і т.д. Для кожного з таких можливих подій АБД повинні мати план дій. У деяких випадках може знадобитися відновлення носія, в інших буде достатньо відновлення екземпляра. Для обох цих ситуацій АБД повинні мати плани дій. Ми розглянемо їх в цьому розділі нижче. Зрештою, адміністратор бази даних і системний адміністратор повинні документувати середу бази даних і стратегії відновлення, щоб при виникненні збою АБД міг діагностувати проблему і негайно зайнятися її рішенням.
5.1 Планування відновлення примірника
Робота систем може аварійно завершуватися з різних причин, наприклад, через припинення подачі електроенергії. У цьому випадку після перезапуску екземпляра СУБД і до відкриття бази даних для користувачів буде виконуватися відновлення екземпляра. Мета відновлення примірника - відновлення фізичного вмісту бази даних у транзакційно узгоджене стан. Тому під час відновлення повинні застосовуватися всі зроблені зафіксованими транзакціями зміни, які перебували в кеші буферів і не були записані на диск до збою, а потім виконується відкат всіх записаних на диск змін, зроблених незафіксованими транзакціями. Відновлення примірника виконується внутрішніми механізмами СУБД Oracle і не вимагає втручання адміністратора. Єдиний аспект, про який повинен піклуватися АБД - тривалість виколненія відновлення; це легко контролюється налаштуванням у файлі ініціалізації параметра FAST_START_MTTR_TARGET (MTTR - mean time to recover, середній час відновлення). У системах, в яких розмір кеша буферів складає багато гігабайтів, відновлення екземпляра може бути дуже тривалим з абсолютно не передбачуваним часом відновлення. Для АБД обидва ці властивості мало припустимі. Нова опція швидкого відновлення з передбачуваним часом (Fast-Start Time-Based Recovery) в СУБД Oracle9i дозволяє АБД задавати середній час відновлення примірника (у секундах) за допомогою установки значення в параметрі FAST_START_MTTR_TARGET. Ця опція реалізується обмеженням кількості «брудних» буферів і кількості журнальних записів, згенерованих після останньої контрольної точки. Для забезпечення заданого часу відновлення сервер бази...
