Відновлюємо контрольний файл
Втрата або пошкодження контрольного файлу-це перша неприємність, яка вас може чекати під час спроби стартувати примірник СУБД Oracle. Виявляється вона відразу при спробі монтувати систему: у відповідь на startup mount в svrmgrl або в sqlplus ви отримаєте повідомлення типу
ORA-00205: error in identifying controlfile, check alert log for more info
Для того, щоб зрозуміти, чому так відбувається і трошки зорієнтуватися в подальших діях, досить згадати про його ролі. Контрольний файл (control file, можна ще сказати "файл контролю коректності стану СУБД", це більш правильно, але трохи довший) - це файл зі спеціальною "базою даних", з інформацією про поточний стан таких об'єктів СУБД, як табличних просторів, файлів - з даними і журнальних. Один з найважливіших відслідковуються контрольним файлом параметрів є "послідовний номер змін в системі" (system change number, SCN). Номер SCN видається системою кожен починає транзакції, і коли зміни потрапляють в файл даних, цей номер заноситься в заголовок файлу і в контрольний файл одночасно (природно, що крім цього SCN потрапляє і в журнальні файли). При запуску СУБД система порівнює SCN з заголовка файлу з SCN, записаним для цього файлу у себе. Якщо номер у файлі виявляється старше ніж треба, потрібне відновлення файлу з даними. Якщо в цій ситуації підмінити контрольний файл старою версією, можна отримати повідомлення про помилку "контрольний файл застарів". Це те, що стосується синхронізації файлів системи. Але в контрольному файлі зберігається ще й інша інформація про СУБД - наприклад, максимальне число файлів в групі журналу та інше.
Неприємність з контрольним файлом може виникнути при збоях або необережному використанні файлової системи, або ж при неакуратному відновлення резервної копії БД. Але оскільки для роботи Oracle контрольний файл життєво важливий, псування його або зникнення роблять роботу з БД неможливою. Для того, щоб убезпечити користувача від таких ситуацій, в Oracle є механізм віддзеркалення контрольних файлів, що дозволяє заводити кілька копій файлу, за змістовною ідентичністю яких система стежить сама. Але все ж, якщо не дивлячись на "неодноразові попередження Міністерства охорони здоров'я" контрольний файл у адміністратора "подзалетел", що ж робити. Багато що залежить від конкретних обставин неприємності. Нижче наводиться можлива послідовність дій.
Отже, що ж робити, якщо неприємність з контрольним файлом не дає можливості монтувати систему (згадаємо, що саме актом читання контрольного файлу відрізняється обробка startup mount від startup nomount).
Дія 1. Для початку потрібно визначитися з наявністю контрольних файлів і з тим, який саме файл викликав неприємність. Так як система непрацездатна, доведеться звернутися до файлу INIT.ORA або CONFIG.ORA і знайти там пропозицію control_files = (...) з переліком дзеркальних копій файлу, або із зазначенням одного, коли дзеркальних копій немає.
Потім потрібно звернутися в "журнал для реєстрації вступників сигналів з місць" (alert log). Зазвичай він розташований в каталозі ORACLE_BASE / ORACLE_SID / admin / bdumb. але може бути і в іншому місці, наприклад, зазначеним в параметрі background_dump_dest в INIT.ORA або CONFIG.ORA (у версіях 8.0 і раніше в Windows NT він може бути ні там, ні там, але його легко знайти) - в файлі alert_ORACLE_SID. log. Там виявиться повідомлення типу такого:
ORA-00202: controlfile: 'E: \ Oracle \ oradata \ db1 \ control01.ctl'
ORA-27041: unable to open file
OSD-04002: unable to open file
O / S-Error: (OS 2) The system can not find the file specified.
Тепер потрібно придивитися до реальних файлах, порівняти їх розміри і дати змін і визначитися з ситуацією і подальшими діями.
Файл, на який грішить Oracle, відсутня, але є хоча б одна його копія.
Перейти до кроку 2.
Файл, на який лається Oracle, в наявності, але пошкоджений.
Якщо пошкодження файлу неочевидно, висновок про це стає суб'єктивним, тобто справою вибору (інтуїції, досвіду) АБД. Переконатися в правильності вибору тоді допоможе "гра в підстановки" копій контрольного файлу, описана в кроці 2. З цього моменту перш ніж рухатися далі настійно рекомендується зняти копії всіх наявних контрольних файлів.
Якщо все оперативні (online) журнальні файли на місці, то, можливо, найбільш простий сценарій подальших дій - переконатися в наявності всіх файлів з даними і журнальних файлів (дії 3 і 4) і перебудувати контрольний файл командою create controlfile (дії 5 і 6) .
Контрольні файли або повністю отсутствую, або все мають різні розміри і дати змін.
Можна прийняти висновок, що всі контрольні файли пошкоджені, і що їх усіх потрібно відновити, або ж відновити всю БД по резервної копії. Останнє можливо, якщо (треба сподіватися) при резервному копіюванні ви не забували виконувати backup control file to trace (по цій команді створюється SQL-послідовність для регенерації контрольного файлу). Якщо цього не робилося, доводиться переходити до дії 7, а якщо так (ви робили backup) - то до дій з 3-го по 6-е).
Дія 2. Намагаємося підставити придатний контрольний файл. Отже, Oracle скаржиться або на відсутній, або на поганий контрольний файл. Ще раз перевіряємо, що файлової системою зняли копії всіх наявних контрольних файлів.
Якщо стартувати Oracle вийшли - прекрасно; якщо немає - переходимо на дії 3 - 6 по створенню контрольного файлу заново.
Крок 3. Намагаємося визначити, чи в порядку всі файли з даними і оперативні файли журналу. Це потрібно знати, тому що без цього не можна запускати сценарій створення контрольного файлу (дія 6). Якщо аварія з контрольним файлом сталася після невдалого відновлення резервної копії, і з'ясовується, що файли з даними - давніші, ніж треба, це може виявитися не страшно і можна виправити за допомогою відновлення media recovery. Однак, для можливості відпрацювання дії 6 необхідно, щоб оперативні файли журналу були в цілості й відповідали поточному стану системи.
Це пов'язано з тим, що при створенні контрольного файлу система буде заглядати в кожен файл даних і перевіряти його SCN. Якщо буде виявлено, що SCN з файлу - більш пізній, ніж всі номери SCN, що фігурують в файлах оперативного журналу, процес створення буде обірваний.
Якщо ви прийшли до твердого думку, що якийсь з файлів даних або оперативного журналу непридатний до використання, потрібно переходити до наступного кроку. В іншому випадку можна перейти до дії 5.
Крок 4. Відновлюємо файли даних або журналу, що опинилися непридатними. Ще раз: якщо ви не впевнені, що якісь з файлів непридатні, і що дуже ймовірно, що з файлами все нормально, то можете, при бажанні, перейти відразу до дії 5, і при невдачі повернутися знову сюди. Біди від цього не буде.
Для початку визначимося з наявністю файлів. Перелік файлів, які повинні бути, можна отримати, увійшовши в svrmgrl або в sqlplus (в останньому випадку рекомендується видати sqlplus / nolog), видавши connect internal, а потім послідовно
select name from v $ datafile;
select group #, member from v $ logfile;
(Згадаймо, що v $ - "таблиці" фізично зберігаються не в файлах, а в SGA, і доступні тому і при невідкритої БД).
Спочатку слід придивитися до файлів даних. Якщо якісь з них в файлової системі відсутні, або мають нульову довжину, або мають більш пізню дату зміни, ніж самий останній оперативний журнальний файл, - їх доведеться відновлювати по резервної копії.
З журнальними файлами ситуація трошки інша. Потрібно перевірити на однаковість довжини і дати зміни всіх файлів усередині однієї групи. Природно, що довжини повинні бути ненульовими, а дати осмисленими. Неприємність може мати дві різні забарвлення:
У кожній групі знайдеться хоча б один нормальний журнал.
Хоча б одна група пошкоджена цілком.
Це погана ситуація, тому що створення контрольного файлу (дія 5) вимагає наявності всіх оперативних журналів. Доведеться повністю відновлювати БД і виконувати alter database open resetlogs, про що як-небудь буде окрема розмова.
Крок 5. Шукаємо сценарій створення контрольного файлу - добре б він знайшовся вже готовий. Він може бути, якщо ви видавали команду alter database backup control file to trace, коли ще все працювало. Тому непогано таку команду виконувати регулярно і автоматично, наприклад, за допомогою cron в Unix.
Сценарій, створений цією командою, потрапляє в файл трасування. В NT (версія 8.1 Oracle) цей файл зберігається за замовчуванням в ORACLE_BASE \ Admin \ ORACLE_SID \ udump, а інше місце зберігання може бути задано параметром user_dump_dest в файлі ініціалізації СУБД. Файлів трасування (зазвичай вони носять розширення trc) може бути кілька, і тоді серед них потрібно знайти той з найбільш пізньої командою create controlfile (в різних ОС для цього є різні можливості; в NT, наприклад, багато доведеться попрацювати очима, а в Unix - руками і головою) і перейти до дії 6. Якщо файлів трасувань з командою створення контрольного файлу не виявиться в наявності, переходимо до кроку 7.
Якщо все спрацювало, вважайте, що ви відбулися легким переляком і відпочиньте. Інакше (наприклад, з'ясувалося, що оперативні файли журналу пошкоджені) - переходимо до наступного кроку.
Крок 7. Пробуємо відновити контрольний файл за резервною копії, готуємося до відновлення БД і намагаємося її відновити. Те, що ми дійшли до цього кроку, є, безумовно, наслідок катаклізму. Судіть: ми загубили всі працездатні копії контрольного файлу, сценарій його відновлення (якщо його коли-небудь формували!) І все цілі копії в щонайменше в одній з груп оперативних журналів.
Вибір невеликий. Тепер можна або відкотитися на n годин, діб, тижнів тому по холодній копії, або ж спробувати відновити останній придатний контрольний файл за однією з резервних копій і, користуючись ним, відновити БД. Але це вимагає окремої розмови.