Відновлюємо контрольний файл, Резервне копіювання, Різне, статті

Втрата або пошкодження контрольного файла-це перша неприємність, яка вас може очікувати при спробі стартувати примірник СУБД 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:Oracleoradatadb1control01.ctl”

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) The system cannot 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 скаржиться або на відсутній, або на поганий контрольний файл. Ще раз перевіряємо, що файлової системою зняли копії всіх готівкових контрольних файлів.

Спочатку дивимося в журналі alert log, який файл непридатний (див. вище). Пробуємо підставити на його місце придатний (на нашу думку) файл і “виливаємо воду з каструльки” – робимо startup mount. Якщо дзеркальних копій кілька (або негідний файл точно невідомий), підставляти “придатний” файл доведеться по черзі кілька разів і на місце всіх копій відразу (команда copy файлової системи).

Якщо стартувати 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, і доступні тому і при невідкритої БД).

Спочатку слід придивитися до файлів даних. Якщо якісь із них у файловій системі відсутні, або мають нульову довжину, або мають більш пізню дату зміни, ніж самий останній оперативний журнальний файл, – їх доведеться відновлювати за резервною копії.

З журнальними файлами ситуація трошки інша. Потрібно перевірити на однаковість довжини і дати зміни всіх файлів всередині однієї групи. Природно, що довжини повинні бути ненульовими, а дати осмисленими. Неприємність може мати дві різних забарвлення:

У кожній групі знайдеться хоча б один нормальний журнал.

Це хороша ситуація. Якщо в групі є і ненормальні журнали, звичайною командою ОС copy на їх місце копіюються нормальні. Віддзеркалення в нагоді!

Хоча б одна група пошкоджена цілком.

Це погана ситуація, тому що створення контрольного файлу (дія 5) вимагає наявності всіх оперативних журналів. Доведеться повністю відновлювати БД і виконувати alter database open resetlogs, про що-небудь буде окрема розмова.

Дія 5. Шукаємо сценарій створення контрольного файлу – добре б він знайшовся вже готовий! Він може матися, якщо ви видавали команду alter database backup control file to trace, коли ще все працювало. Тому непогано таку команду виконувати регулярно і автоматично, наприклад, за допомогою cron в Unix.

Сценарій, створений цією командою, потрапляє в файл трасування. В NT (версія 8.1 Oracle) цей файл зберігається за замовчуванням в ORACLE_BASEAdminORACLE_SIDudump, а інше місце зберігання може бути задано параметром user_dump_dest у файлі ініціалізації СУБД. Файлів трасування (зазвичай вони носять розширення trc) може бути декілька, і тоді серед них потрібно знайти той з найбільш пізньої командою create controlfile (в різних ОС для цього є різні можливості; в NT, наприклад, багато доведеться попрацювати очима, а в Unix – руками і головою) і перейти до дії 6. Якщо трасувань файлів з командою створення контрольного файлу не виявиться в наявності, переходимо до дії 7.

Дія 6. Запускаємо сценарій створення контрольного файлу. Для цього копіюємо файл трасування (див. попереднє дію) у файл, наприклад, rebuild.sql. Видаляємо в текстовому редакторі все, що варто до фрази “# The following commands will create … “і після останнього речення SQL, що йде по тексту. У самий початок додаємо connect internal – і файл можна подавати на вхід srvmgrl (нагадаємо, що СУБД не запущена).

Якщо все спрацювало, вважайте, що ви відбулися легким переляком і відпочиньте. Інакше (наприклад, з’ясувалося, що оперативні файли журналу пошкоджені) – переходимо до наступного кроку.

Крок 7. Пробуємо відновити контрольний файл за резервною копії, готуємося до відновлення БД і намагаємося її відновити. Те, що ми дійшли до цього кроку, є, безумовно, наслідок катаклізму. Судіть: ми загубили всі працездатні копії контрольного файлу, сценарій його відновлення (якщо його коли-небудь формували!) і всі цілі копії у щонайменше в одній з груп оперативних журналів.

Вибір невеликий. Тепер можна або відкотитися на n годин, діб, тижнів тому по холодній копії, або-таки спробувати відновити останній придатний контрольний файл за однією з резервних копій і, користуючись їм, відновити БД. Але це вимагає окремої розмови.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*