Владимир Пржиялковский
21 января 2000 г.

Потеря или повреждение контрольного файла– это первая неприятность, которая вас может ожидать при попытке стартовать экземпляр СУБД 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 часов, суток, недель назад по холодной копии, либо-таки попытаться восстановить последний годный контрольный файл по одной из резервных копий и, пользуясь им, восстановить БД. Но это требует отдельного разговора.