数据库完全恢复与Resetlogs

很多朋友经常会对完全恢复与Resetlogs产生误解，以为使用Resetlogs方式打开数据库就是不完全恢复，这种看法是不正确的。
只要拥有当前的日志文件，那么就能够对数据库执行完全恢复，而是否需要使用Resetlogs方式打开，则取决于是否使用的是备份的控制文件。如果使用的是备份的控制文件则需要使用Resetlogs方式打开数据库；如果拥有当前的控制文件或者通过重建控制文件来恢复，就不需要通过Resetlogs方式打开数据库。
下面通过两个试验来讨论一下Oracle的恢复控制，以下两个试验的前提是日志文件完好，而其他数据文件、控制文件全部损失。

（1）使用备份控制文件进行恢复。

首先对数据库执行一次全备份，由于数据库启用了控制文件的自动备份，在全备份完成后Oracle将自动执行控制文件的备份：

RMAN> backup database format '/opt/oracle/backup/full%T';

Starting backup at 2007-05-12 22:24:28
。。。。。。。。
Finished backup at 2007-05-12 22:26:35

Starting Control File and SPFILE Autobackup at 2007-05-12 22:26:37
piece handle=/opt/oracle/product/9.2.0/dbs/c-1407686520-20070512-00 comment=NONE
Finished Control File and SPFILE Autobackup at 2007-05-12 22:26:40
复制

然后可以在数据库中执行一系列的DML操作，生成一系列的归档日志，最后强制删除所有的数据文件、控制文件，模拟一次数据库故障。接下来开始尝试恢复，首先通过控制文件的自动备份恢复出控制文件：

RMAN> startup nomount;
Oracle instance started

RMAN> set dbid=1407686520
executing command: SET DBID
RMAN> restore controlfile from autobackup;
Starting restore at 2007-05-12 22:32:26

using channel ORA_DISK_1
channel ORA_DISK_1: looking for autobackup on day: 20070512
channel ORA_DISK_1: autobackup found: c-1407686520-20070512-00
channel ORA_DISK_1: controlfile restore from autobackup complete
replicating controlfile
input filename=/opt/oracle/oradata/eygle/control01.ctl
Finished restore at 2007-05-12 22:32:29
复制

然后开始执行备份文件的回复工作：

RMAN> alter database mount;
RMAN> restore database;
复制

最后可以通过RMAN执行介质恢复：

RMAN> recover database;
复制

由于恢复使用的是备份的控制文件，所以Oracle要求必须使用Resetlogs的方式打开数据库：

RMAN> alter database open;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 05/12/2007 22:35:43
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
复制

由于没有损失当前的日志文件，所以恢复可以做到完全恢复，也就是说可以恢复到最后一次成功完成的Commit操作，使用SQLPlus手工恢复过程可以更清晰地看到这个过程，在以上步骤中，当完成数据文件回复之后，可以通过SQLPlus来手工执行恢复。
由于是使用的备份控制文件，Oracle要求必须使用Backup Controlfile的选项来执行恢复：

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
复制

在恢复过程中Oracle会依次应用归档日志：

SQL> recover database using backup controlfile;          
ORA-00279: change 18997660553 generated at 05/12/2007 22:24:28 needed for thread 1
ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_31.dbf
ORA-00280: change 18997660553 for thread 1 is in sequence #31
………………
复制

直至最后一个日志无法找到为止：

ORA-00308: cannot open archived log '/opt/oracle/product/9.2.0/dbs/arch1_34.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
复制

这个最后的归档日志请求的实际上就是在线的尚未归档的日志文件，可以手工指定这个文件名称：

SQL> recover database using backup controlfile;
ORA-00279: change 18997660690 generated at 05/12/2007 22:28:08 needed for thread 1
ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_34.dbf
ORA-00280: change 18997660690 for thread 1 is in sequence #34

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/opt/oracle/oradata/eygle/redo03.log
Log applied.
Media recovery complete.
复制

输入日志文件后，Oracle提示日志内容得到应用，介质恢复成功完成，也就是说所有日志都已经成功应用，实际上这已经是完成了一次完全恢复，只不过使用的是备份的控制文件，Oracle需要以Resetlogs方式来打开数据库：

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
复制

在这种情况下，之所以Oracle要求以Resetlogs来重置日志文件，是因为当使用备份的控制文件进行恢复，Oracle已经假定数据库发生了严重的介质故障。丢失了当前的控制文件之后，Oracle已经无法判断哪一个日志文件才是最后的Current的日志文件；即使通过一个日志文件完成了一个完全恢复，那么这个完全恢复也可能只是一个阶段性的，也就是说这个日志文件可能仅仅是Redo Stream里的一个中间阶段而已。

所以如果恢复执行到了某一个日志文件停止，Oracle依据用户的意图，假定这个状态是用户期待的最佳状态，那么Oracle必须要确保在这个Redo Stream里的其他日志不被应用，归档日志是可以被逐步应用用于恢复的，而且在恢复的中间阶段数据库甚至可以只读打开，所以一旦用户的意志被确定下来，Oracle要以读写方式打开数据库，必须执行Resetlogs。

对于以上测试，如果日志文件没有损失，则可以通过重建控制文件的方法来完成完全恢复，在这种情况下，就不再需要通过Resetlogs的方式来打开数据库了。

（2）通过重建控制文件进行恢复。

在测试之前执行一次全库备份，并拥有了控制文件的自动备份，这些步骤和上一个测试完全相同。
因为丢失了当前的控制文件，在执行恢复时，同样从自动备份中恢复一个控制文件：

RMAN> startup nomount;
Oracle instance started
RMAN> restore controlfile 
   2 from '/opt/oracle/product/9.2.0/dbs/c-1407686520-20070513-03';
Starting restore at 2007-05-13 12:45:05

using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=10 devtype=DISK
channel ORA_DISK_1: restoring controlfile
channel ORA_DISK_1: restore complete
replicating controlfile
input filename=/opt/oracle/oradata/eygle/control01.ctl
Finished restore at 2007-05-13 12:45:12
复制

然后通过这个备份的控制文件来回复备份的数据文件：

RMAN> alter database mount;
database mounted
RMAN> restore database;
复制

我们可以通过转储当前的控制文件为跟踪文件，获得创建控制文件的脚本：

SQL> alter database backup controlfile to trace;
Database altered.
复制

关闭数据库，启动到nomount状态，重建控制文件：

SQL> CREATE CONTROLFILE REUSE DATABASE "EYGLE" NORESETLOGS  ARCHIVELOG
  2  --  SET STANDBY TO MAXIMIZE PERFORMANCE
  3      MAXLOGFILES 5
  4      MAXLOGMEMBERS 3
  5      MAXDATAFILES 100
  6      MAXINSTANCES 1
  7      MAXLOGHISTORY 1134
  8  LOGFILE
  9    GROUP 3 '/opt/oracle/oradata/eygle/redo03.log'  SIZE 1M,
 10    GROUP 4 '/opt/oracle/oradata/eygle/redo04.dbf'  SIZE 1M,
 11    GROUP 5 '/opt/oracle/oradata/eygle/redo05.dbf'  SIZE 1M
 12  -- STANDBY LOGFILE
 13  DATAFILE
 14    '/opt/oracle/oradata/eygle/system01.dbf',
 15    '/opt/oracle/oradata/eygle/undotbs01.dbf',
 16    '/opt/oracle/oradata/eygle/users.dbf'
 17  CHARACTER SET ZHS16GBK
 18  ;

Control file created.
复制

接下来的恢复就可以顺利进行了：

SQL> recover database;
ORA-00279: change 18997676883 generated at 05/13/2007 12:39:15 needed for thread 1
ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_8.dbf
ORA-00280: change 18997676883 for thread 1 is in sequence #8

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    
ORA-00279: change 18997676947 generated at 05/13/2007 12:41:03 needed for thread 1
ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_9.dbf
ORA-00280: change 18997676947 for thread 1 is in sequence #9
ORA-00278: log file '/opt/oracle/product/9.2.0/dbs/arch1_8.dbf' no longer needed for this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 18997676975 generated at 05/13/2007 12:41:22 needed for thread 1
ORA-00289: suggestion : /opt/oracle/product/9.2.0/dbs/arch1_10.dbf
ORA-00280: change 18997676975 for thread 1 is in sequence #10
ORA-00278: log file '/opt/oracle/product/9.2.0/dbs/arch1_9.dbf' no longer needed for this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Log applied.
Media recovery complete.
复制

在完成完全恢复之后，数据库可以正常打开：

SQL> alter database open;
Database altered.
复制