丢失控制文件的恢复

9.3.3  丢失控制文件的恢复

前面曾经提到，在NOCATALOG模式下，RMAN创建的备份信息都将保存在目标数据库的控制文件中，所以一旦控制文件丢失，不仅目标数据库崩溃，连RMAN的备份信息也尽数丢失，这种情况下，如果您有控制文件备份，那还有救（没有备份的话，也并非完全没有希望，如果DBA对自己的Oracle数据库结构非常了解，可以通过写脚本的方式重建控制文件。你看Oracle是不是考虑的很周全？很多情况下你认为没救了的时候，也并非完全陷入绝境）。

本小节将模拟在归档模式下，控制文件丢失时的恢复，在本例中，我们仍然借助前面章节中建立的备份做恢复。

注 意

在恢复控制文件之前，必须知道目标数据库的DBID。关于数据库的DBID，有多种方式可查，比如创建自动备份时，如果没有更改其命名方式，文件名中会包含DBID；或者查看之前的RMAN备份日志，登录到RMAN之后会显示出目标数据库的DBID。

下面演示丢失控制文件的恢复过程。

1．模拟文件丢失

正在操作数据中：

SQL> INSERT INTO JSS.BOOK_LIST VALUES
(2, 'ABOUT SANSI',SYSDATE);
1 row created.
SQL> commit;
Commit complete.

由于控制文件在Oracle数据库运行期间会被Oracle进程锁定，无法直接删除，因此这里还是按照前面模拟丢失数据文件的方式，首先SHUTDOWN数据库，然后再删除控制文件：

SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST DEL f:/oracle/oradata/jssbook/control*
SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area  314572800 bytes
Fixed Size                  1248720 bytes
Variable Size              67109424 bytes
Database Buffers          239075328 bytes
Redo Buffers                7139328 bytes

由于控制文件丢失，肯定是启动不到MOUNT状态了，因此最后将数据库启动到NOMOUNT状态。

2．恢复控制文件

新开一个窗口，连接到RMAN命令行：

C:/Documents and Settings/junsansi>SET ORACLE_SID=jssbook
C:/Documents and Settings/junsansi>RMAN TARGET /
Recovery Manager: Release 10.2.0.1.0 - Production on
Wed Apr 29 22:58:25 2009
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
connected to target database: jssbook (not mounted)

目标数据库控制文件丢失，无法启动到MOUNT状态，此处必须首先指定DBID：

RMAN> SET DBID=1415261003
executing command: SET DBID

前面创建备份时都是在NOCATALOG模式下进行的，因此备份信息、备份设置等都是存储在目标数据库的控制文件中，现在控制文件丢失，相当于前面的一些配置也丢失了，用SHOW ALL命令查看，可见所有配置均恢复成了默认值，例如：

RMAN> SHOW ALL;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE
DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO
BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK
TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
# default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
此时要恢复控制文件，不能直接使用RESTORE CONTROLFILE

FROM AUTOBACKUP命令，因为自动备份的设置也丢失了，并且此时也是在NOCATALOG模式下，无法配置CONTROLFILE AUTOBACKUP的相关属性，因此选择显式指定控制文件备份集的方式恢复控制文件。执行命令如下：

RMAN> RESTORE CONTROLFILE FROM 'f:/oracle/backup
/C-1415261003-20090429-00';
Starting restore at 29-APR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL01.CTL
output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL02.CTL
output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL03.CTL
Finished restore at 29-APR-09

提 示

指定控制文件备份集时，记得要找一个稍新一点的控制文件。另外如果恢复时没有指定TO子句，则控制文件会被恢复到初始化参数CONTROL_FILES指定的路径下。

有了控制文件，就可以将数据库置为MOUNT状态了：

RMAN> ALTER DATABASE MOUNT;
database mounted
released channel: ORA_DISK_1

由于只是控制文件丢失，数据文件仍在，因此并不需要对整个数据库进行修复操作，只需要执行RECOVER命令，重新应用备份的控制文件后生成的那些重做日志即可：

RMAN> RECOVER DATABASE;
Starting recover at 29-APR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
starting media recovery
archive log thread 1 sequence 47 is already on disk as file
F:/ORACLE/ORADATA/JSSBOOK/REDO02.LOG
archive log filename=F:/ORACLE/ORADATA/JSSBOOK/REDO02.
LOG thread=1 sequence=47
media recovery complete, elapsed time: 00:00:02
Finished recover at 29-APR-09

如果上述命令均正常执行，就可以打开数据库了：

RMAN> ALTER DATABASE OPEN RESETLOGS;
database opened

下面切换到SQL*Plus命令行环境下，看看数据是否都在：

SQL> SELECT *FROM BOOK_LIST;
    BOOKID BOOKNAME
---------- -------------------------------
         2 About Sansi
         1 Sansi's Note

OK，一切正常。怎么样，你的操作都顺利吗？