很多朋友经常会对完全恢复与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.
