Неблагодарное это дело – восстановление безвозвратно упавшей БД. Мое мнение – надежней всего делать полный дамп, копии скриптов создания всех своих пользователей, создания ролей, синонимов и контекстов. Тем не менее, выдался случай, когда в наличии только копия (да еще горячая!) всей структуры файлов сервера и работавших на нем экземпляров (instance). Первое, что стоит отметить (да об этом и весь интернет говорит), если уж и делать копию то холодную. И не стоит забывать о создании шаблона актуальной версии controlfile’а! Это на тот случай, если новая платформа, куда срочно понадобится восстановить базу, будет отличаться разрядностью.
Наш случай оказался прилично запущенным:
- В наличии только горячая копия.
- Упавший сервер работал на 32-битной платформе, а восстановление проходит на 64-битной, что автоматически приводит к необходимости переноса между платформами и наличию шаблона управляющих файлов (controlfiles).
- Шаблон управляющих файлов отсутствует.
- На упавшем сервере был установлены (но не использовались) дополнительные модули. На новой платформе их нет.
А теперь попробуем со всем этим взлететь.
С горячей копией первым делом мы натыкаемся на рассинхронизацию управляющих файлов. Да это практически то же самое, что выключить сервер без остановки БД. С ошибкой ORA-00214 – Controlfiles inconsistent мы уже сталкивались. Как с ней бороться было описано в одноименной заметке. За исключением одной детали: команда alter database open; приводит к сообщению:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Запустить БД в ограниченном режиме в этом случае можно командой:
-- сразу startup upgrade -- или по частям startup nomount alter database mount; alter datbase open upgrade;
Идем дальше. Восстанавливаемая БД работала на 32-битной платформе, а для восстановления в распоряжении имеется только 64-битная платформа. Необходимо сделать преобразование ряда системных файлов и объектов к 64-разрядному виду. Сверяемся со схемой перехода на 64-битную платформу. Т.к. заранее переход не планировался, никаких заготовленных заранее шаблонов control-файлов в наличии нет. Поэтому берем заготовку
CREATE CONTROLFILE REUSE DATABASE SID NORESETLOGS NOARCHIVELOG MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXDATAFILES 100 MAXLOGHISTORY 1 LOGFILE GROUP 1 'ORACLE_BASE/oradata/SID/redo01.log' SIZE 50M, GROUP 2 'ORACLE_BASE/oradata/SID/redo02.log' SIZE 50M, GROUP 3 'ORACLE_BASE/oradata/SID/redo03.log' SIZE 50M DATAFILE 'ORACLE_BASE/oradata/SID/system01.dbf', 'ORACLE_BASE/oradata/SID/TEMP01.dbf', 'ORACLE_BASE/oradata/SID/tools01.dbf', 'ORACLE_BASE/oradata/SID/sysaux01.dbf', 'ORACLE_BASE/oradata/SID/undotbs02.dbf', 'ORACLE_BASE/oradata/SID/users01.dbf' CHARACTER SET AL32UTF8;
и приводим ее к соответствующему виду самостоятельно без шаблонов. Но это еще не все. Копирование-то не было холодным, поэтому при попытке создания control-файлов получаем ошибки доступа к файлам табличного пространства. Восстанавливаем файлы командой recover.
connect / as sysdba shutdown immediate startup mount -- проверяем состояние файлов табличных пространств (UNDOTBS01.DBF находится в состянии RECOVER) select file#,status,name from v$datafile; FILE# STATUS NAME ---------- ------- ---------------------------------------------------------------------------------------- 1 SYSTEM ORACLE_BASE/oradata/SID/SYSTEM01.DBF 2 RECOVER ORACLE_BASE/oradata/SID/UNDOTBS01.DBF 3 ONLINE ORACLE_BASE/oradata/SID/TOOLS01.DBF 4 ONLINE ORACLE_BASE/oradata/SID/USERS01.DBF 5 ONLINE ORACLE_BASE/oradata/SID/TEMP01.DBF 6 ONLINE ORACLE_BASE/oradata/SID/SYSAUX01.DBF 7 ONLINE ORACLE_BASE/oradata/SID/USERS01.DBF -- восстанавливаем файл табличного пространства recover datafile 2; -- проверяем что получилось SQL> select file#,status,name from v$datafile; FILE# STATUS NAME ---------- ------- ---------------------------------------------------------------------------------------- 1 SYSTEM ORACLE_BASE/oradata/SID/SYSTEM01.DBF 2 OFFLINE ORACLE_BASE/oradata/SID/UNDOTBS01.DBF 3 ONLINE ORACLE_BASE/oradata/SID/TOOLS01.DBF 4 ONLINE ORACLE_BASE/oradata/SID/USERS01.DBF 5 ONLINE ORACLE_BASE/oradata/SID/TEMP01.DBF 6 ONLINE ORACLE_BASE/oradata/SID/SYSAUX01.DBF 7 ONLINE ORACLE_BASE/oradata/SID/USERS01.DBF -- переводим файл в состояни ONLINE alter database datafile 2 online; select file#,status,name from v$datafile; FILE# STATUS NAME ---------- ------- ---------------------------------------------------------------------------------------- 1 SYSTEM ORACLE_BASE/oradata/SID/SYSTEM01.DBF 2 ONLINE ORACLE_BASE/oradata/SID/UNDOTBS01.DBF 3 ONLINE ORACLE_BASE/oradata/SID/TOOLS01.DBF 4 ONLINE ORACLE_BASE/oradata/SID/USERS01.DBF 5 ONLINE ORACLE_BASE/oradata/SID/TEMP01.DBF 6 ONLINE ORACLE_BASE/oradata/SID/SYSAUX01.DBF 7 ONLINE ORACLE_BASE/oradata/SID/USERS01.DBF
После восстановления файла табличного пространства UNDO возникает рассинхронизация с сегментами REDO (ORA-00600: internal error code, arguments: [4194]). Для исправления ситуации необходимо пересоздать файл UNDOTBS01.DBF.
shutdown immediate startup nomount; create pfile from spfile; shutdown immediate /* В полученном PFILE комментируем строку undo_tablespace=UNDOTBS1 и добавляем строку undo_management=MANUAL: undo_management=MANUAL #undo_tablespace=UNDOTBS1 */ startup nomount; create spfile from pfile; alter database mount; -- удаление старого табличного пространства alter database datafile 'ORACLE_BASE/oradata/SID/undotbs01.dbf' offline drop; alter database open upgrade; drop tablespace UNDOTBS1 INCLUDING CONTENTS and datafiles; -- создание нового табличного пространства CREATE UNDO TABLESPACE undotbs DATAFILE 'ORACLE_BASE/oradata/SID/undotbs02.dbf' SIZE 100M; shutdown immediate /* Возвращаем обратно параметр конфигурационного файла: #undo_management=MANUAL undo_tablespace=UNDOTBS1 */ startup nomount; create spfile from pfile; shutdown immediate
Коме того, может понадобиться восстановление временного табличного пространства. Теперь все готово для создания новых control-файлов и апгрейда БД.
cd $ORACLE_HOME/rdbms/admin sqlplus / as sysdba
startup nomount; CREATE CONTROLFILE REUSE DATABASE SID NORESETLOGS NOARCHIVELOG MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXDATAFILES 100 MAXLOGHISTORY 1 LOGFILE GROUP 1 'ORACLE_BASE/oradata/SID/redo01.log' SIZE 50M, GROUP 2 'ORACLE_BASE/oradata/SID/redo02.log' SIZE 50M, GROUP 3 'ORACLE_BASE/oradata/SID/redo03.log' SIZE 50M DATAFILE 'ORACLE_BASE/oradata/SID/system01.dbf', 'ORACLE_BASE/oradata/SID/TEMP01.dbf', 'ORACLE_BASE/oradata/SID/tools01.dbf', 'ORACLE_BASE/oradata/SID/sysaux01.dbf', 'ORACLE_BASE/oradata/SID/undotbs02.dbf', 'ORACLE_BASE/oradata/SID/users01.dbf' CHARACTER SET AL32UTF8; -- остановка БД SHUTDOWN IMMEDIATE; -- запуск в режиме обновления STARTUP UPGRADE; -- обновление объектов @utlirp.sql; -- перекомпиляция объектов PL/SQL @utlrp.sql;
В заключение остается выполнить апгрейд БД в соответствии с нюансами установки данного сервера Oracle с помощью утилиты dbua, после чего БД наконец-то можно запустить в стандартном режиме.
shutdown immediate startup
