Възстановяване на контролния файл
Загубата или повредата на контролния файл е първият проблем, който можете да очаквате, когато се опитвате да стартирате екземпляр на Oracle DBMS. Открива се незабавно при опит за монтиране на системата: в отговор на монтирането при стартиране в svrmgrl или в sqlplus ще получите съобщение като
ORA-00205: грешка при идентифициране на контролния файл, проверете регистъра на предупрежденията за повече информация
За да разберете защо това се случва и да се ориентирате малко в по-нататъшните действия, достатъчно е да си припомните ролята му. Контролният файл (контролен файл, можете също да кажете „контролен файл за коректност на състоянието на СУБД“, това е по-правилно, но малко по-дълго) е файл със специална „база данни“ с информация за текущото състояние на такива СУБД обекти като таблични пространства, файлове - с данни и дневник. Един от най-важните параметри, проследявани от контролния файл, е „поредният брой промени в системата“ (номер на промяна на системата, SCN). SCN номерът се издава от системата за всяка инициирана транзакция и когато промените влязат във файла с данни, този номер се въвежда едновременно в заглавката на файла и в контролния файл (естествено, SCN също попада във файловете за повторение). Когато СУБД се стартира, системата сравнява SCN от заглавката на файла със SCN, записан за този файл самостоятелно. Ако номерът във файла е по-стар, отколкото трябва да бъде, файлът с данни трябва да бъде възстановен. Ако замените контролния файл с по-стара версия в тази ситуация, може да получите съобщение за грешка „контролният файл е остарял“. Това се отнася до синхронизирането на системните файлове. Но контролният файл съхранява и друга информация за СУБД - например максималния брой файлове в групата на журнала и т.н.
Проблеми с контролния файл могат да възникнат поради повреди или небрежно използване на файловата система,или при неточно възстановяване на резервно копие на базата данни. Но тъй като контролният файл е жизненоважен за работата на Oracle, неговата повреда или изчезване прави работата с базата данни невъзможна. За да предпази потребителя от подобни ситуации, Oracle разполага с контролен механизъм за дублиране на файлове, който ви позволява да направите няколко копия на файл, чиято идентичност на съдържанието следи самата система. Но все пак, ако въпреки "многократните предупреждения на МЗ" контролното досие на администратора е "раздуто", какво да правя? Много зависи от конкретните обстоятелства на проблема. Следва възможна последователност от действия.
И така, какво да направите, ако проблемът с контролния файл не направи възможно монтирането на системата (припомнете си, че това е действието на четене на контролния файл, което отличава обработката на стартиращо монтиране от стартиращо nomount)?
Действие 1. Първо трябва да определите наличието на контролни файлове и кой файл е причинил проблема. Тъй като системата не работи, ще трябва да отидете до файла INIT.ORA или CONFIG.ORA и да намерите там клаузата control_files = ( : ) със списък с огледални копия на файла или да посочите такъв, когато няма огледални копия.
След това трябва да се обърнете към 'дневник за регистриране на входящи сигнали от полето' (журнал за предупреждения). Обикновено се намира в директорията ORACLE_BASE/ORACLE_SID/admin/bdumb, но може да е и другаде, като например посочено в параметъра background_dump_dump в INIT.ORA или CONFIG.ORA (във версии 8.0 и по-стари на Windows NT може да не е нито там, нито там, но е лесно за намиране) – във файла alert_ORACLE_SID.log. Там ще видите съобщение като това:
ORA-00202: контролен файл: 'E:\Oracle\oradata\db1\control01.ctl'
ORA-27041: не може да се отвори файл
OSD-04002: не може да се отворифайл
O/S-Error: (OS 2) Системата не може да намери посочения файл.
Сега трябва да разгледате по-отблизо реалните файлове, да сравните техните размери и дати на модификация и да вземете решение за ситуацията и по-нататъшните действия.
Файлът, от който Oracle се оплаква, липсва, но има поне едно копие от него.
Отидете на стъпка 2.
Файлът, от който Oracle се оплаква, присъства, но е повреден.
Ако повредата на файла не е очевидна, заключението за това става субективно, тоест въпрос на избор (интуиция, опит) на DBA. „Играта на заместване" на копия на контролния файл, описана в стъпка 2, ще ви помогне да се уверите, че изборът е правилен. От този момент нататък силно се препоръчва да направите копия на всички налични контролни файлове, преди да продължите.
Ако всички онлайн файлове за повторение са налице, тогава може би най-простият сценарий е да се уверите, че всички данни и файлове за повторение са налице (стъпки 3 и 4) и да създадете отново контролния файл с командата create controlfile (стъпки 5 и 6).
Контролните файлове или липсват напълно, или всички имат различни размери и дати на модификация.
Може да се заключи, че всички контролни файлове са повредени и че всички те трябва да бъдат възстановени или цялата база данни може да бъде възстановена от резервно копие. Последното е възможно, ако (да се надяваме) си спомните да изпълните контролния файл за архивиране, който да проследите по време на архивирането (тази команда създава SQL последователност за повторно генериране на контролния файл). Ако това не е направено, трябва да преминете към стъпка 7, а ако да (направили сте архивиране), тогава преминете към стъпки 3 до 6).
Действие 2. Опит за замяна на валиден контролен файл. Така че Oracle се оплаква или от липсващ, или от лош контролен файл. Още веднъж проверявамече файловата система е направила копия на всички налични контролни файлове.
Ако стартирате Oracle се оказа - добре; ако не, преминете към стъпки 3 - 6, за да създадете контролния файл отново.
Стъпка 3: Опитвате се да определите дали всички файлове с данни и онлайн регистрационни файлове са в ред. Трябва да знаете това, защото без него не можете да изпълните скрипта за създаване на контролен файл (стъпка 6). Ако възникне срив на контролния файл след неуспешно възстановяване на резервно копие и се окаже, че файловете с данни са по-стари, отколкото трябва да бъдат, това може да не е проблем и може да бъде коригирано с възстановяване на носителя. Въпреки това, за да работи стъпка 6, онлайн регистрационните файлове трябва да са непокътнати и актуализирани с текущото състояние на системата.
Това е така, защото при създаване на контролен файл системата ще разгледа всеки файл с данни и ще провери неговия SCN. Ако се установи, че SCN на файла е по-стар от всички SCN, които се появяват в онлайн регистрационните файлове, процесът на създаване ще бъде прекратен.
Ако сте стигнали до твърдото заключение, че един от файловете с данни или онлайн регистрационният файл е неизползваем, трябва да преминете към следващата стъпка. В противен случай можете да преминете към стъпка 5.
Стъпка 4. Възстановете данните или регистрационните файлове, които са се оказали неизползваеми. Още веднъж, ако не сте сигурни, че някой от файловете е лош и че е много вероятно всичко да е наред с файловете, тогава можете, ако желаете, да преминете директно към стъпка 5 и ако не успеете, да се върнете отново тук. Няма да има проблеми от това.
Първо, нека определим наличието на файлове. Списък с файлове, които трябва да са налични, може да бъде получен чрез влизане в svrmgrl или в sqlplus (във последния случай се препоръчва да се издаде sqlplus /nolog) чрез издаванесвържете вътрешно и след това последователно
изберете име от v$datafile;
изберете група#, член от v$logfile;
(Припомнете си, че v$-'tables' се съхраняват физически не във файлове, а в SGA и следователно са достъпни дори когато базата данни не е отворена).
Първо, нека да разгледаме файловете с данни. Ако някой от тях липсва във файловата система, или има нулева дължина, или има дата на модификация, по-късна от последното онлайн повторение, те ще трябва да бъдат възстановени от резервно копие.
С файловете на журнала ситуацията е малко по-различна. Необходимо е да се провери за еднаква дължина и дата на модификация на всички файлове в една и съща група. Естествено, дължините трябва да са различни от нула и датите трябва да имат смисъл. Проблемът може да има два различни цвята:
Всяка група съдържа поне един нормален дневник.
Поне една група е напълно повредена.
Това е лоша ситуация, тъй като създаването на контролния файл (стъпка 5) изисква всички онлайн регистрационни файлове да присъстват. Ще трябва напълно да възстановите базата данни и да извършите алтер база данни отворени resetlogs, което по някакъв начин ще бъде отделна тема.
Действие 5. Търсим скрипт за създаване на контролен файл - би било хубаво да е вече готов! Може да е налице, ако сте издали командата за промяна на контролния файл за архивиране на базата данни за проследяване, когато всичко все още работи. Ето защо е добра идея да изпълнявате такава команда редовно и автоматично, например с помощта на cron в Unix.
Скриптът, създаден от тази команда, е включен във файла за проследяване. В NT (версия 8.1 Oracle), този файл се съхранява по подразбиране в ORACLE_BASE\Admin\ORACLE_SID\udump и друго място за съхранение може да бъде указано от параметъра user_dump_dest в инициализационния файл на СУБД. Може да има няколко файла за проследяване (обикновено те имат разширение trc), а след това сред тях се нуждаетенамерете този с най-новата команда за създаване на контролен файл (различните операционни системи имат различни възможности за това; на NT, например, трябва да работите много с очите си, а на Unix - с ръцете и главата си) и преминете към стъпка 6. Ако няма файлове за проследяване с командата за създаване на контролен файл, преминете към стъпка 7.
Ако всичко работи, считайте, че сте се разминали с лека уплаха и почивка. В противен случай (например се оказа, че онлайн лог файловете са повредени) - преминете към следващата стъпка.
Стъпка 7. Опитваме се да възстановим контролния файл от архива, подготвяме се да възстановим базата данни и се опитваме да я възстановим. Фактът, че стигнахме до тази стъпка, определено е следствие от катаклизма. Съдия: загубихме всички работещи копия на контролния файл, скрипта за неговото възстановяване (ако някога е бил формиран!) и всички непокътнати копия в поне една от групите онлайн регистрационни файлове.
Изборът е малък. Сега можете или да върнете n часа, дни, седмици назад, като използвате студено копие, или да опитате да възстановите последния добър контролен файл, като използвате едно от резервните копия и да го използвате за възстановяване на базата данни. Но това изисква отделна дискусия.