27.02.2016 2 min to read

Восстановление БД на Oracle 11gR2 из копии

Category : Статьи

Неблагодарное это дело – восстановление безвозвратно упавшей БД. Мое мнение – надежней всего делать полный дамп, копии скриптов создания всех своих пользователей, создания ролей, синонимов и контекстов. Тем не менее, выдался случай, когда в наличии только копия (да еще горячая!) всей структуры файлов сервера и работавших на нем экземпляров (instance). Первое, что стоит отметить (да об этом и весь интернет говорит), если уж и делать копию то холодную. И не стоит забывать о создании шаблона актуальной версии controlfile’а! Это на тот случай, если новая платформа, куда срочно понадобится восстановить базу, будет отличаться разрядностью.

Наш случай оказался прилично запущенным:

  1. В наличии только горячая копия.
  2. Упавший сервер работал на 32-битной платформе, а восстановление проходит на 64-битной, что автоматически приводит к необходимости переноса между платформами и наличию шаблона управляющих файлов (controlfiles).
  3. Шаблон управляющих файлов отсутствует.
  4. На упавшем сервере был установлены (но не использовались) дополнительные модули. На новой платформе их нет.

А теперь попробуем со всем этим взлететь.

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