模拟rac的不完全恢复，虽然小鱼对常规的完全和不完全恢复已经轻车熟路了，还是记录一个不完全恢复完整过程记录下来。
1 首先小鱼做了一个完全备份。
RMAN> backup database include current controlfile format '/home/oracle/backup_db_%U'
2> plus archivelog format '/db/oracle/backup_arch_%U' delete all input;
然后关闭数据库删除掉所有的数据文件和联机日志文件。
RMAN> shutdown abort;
2 重新启动数据库到mount状态（上面小鱼并没有删除controlfile文件），恢复所有的数据文件
RMAN> startup mount;
RMAN> restore database;
3 由于database备份完成后，还产生了一定的归档日志，而此时我们后面的事情就是确定恢复的终点。
SQL> set heading off;
SQL> select name,first_change#,next_change# from v$archived_log;
。。
+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707
1095851 1095962
+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707
1095854 1095964
+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717
1095962 1095977
+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_4.257.810362719
1095964 1095986
由于最后的归档日志最后的连续点只到scn 1095977，所以这个恢复的终点只能到scn 1095977
RMAN> run{
2> set until scn 1095977;
3> recover database;
4> }
executing command: SET until clause
Starting recover at 18-MAR-13
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707
archive log thread 1 sequence 4 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717
archive log thread 2 sequence 3 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707
archive log thread 2 sequence 4 is already on disk as file +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_4.257.810362719
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=2 sequence=2
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=2
channel ORA_DISK_1: reading from backup piece /db/oracle/backup_arch_0eo4q9n8_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/db/oracle/backup_arch_0eo4q9n8_1_1 tag=TAG20130318T044320
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219 thread=1 sequence=2
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219 thread=2 sequence=2
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707 thread=1 sequence=3
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707 thread=2 sequence=3
archive log filename=+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717 thread=1 sequence=4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/18/2013 04:53:46
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter
database recover logfile
'+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717'
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 4 of thread 2
ORA-00312: online log 4 thread 2: '+ARCH/xiaoyu/onlinelog/group_4.311.810362175'
ORA-17503: ksfdopn:2 Failed to open file +ARCH/xiaoyu/onlinelog/group_4.311.810362175
ORA-15012: ASM file '+ARCH/xiaoyu/onlinelog/group_4.311.810362175' does not exist
ORA-00312: online log 4 thread 2: '+DATA/xiaoyu/onlinelog/group_4.259.810362171'
ORA-17503: ksfdopn:2 Failed to open file +DATA/xiaoyu/onlinelog/grou
小鱼简单说下上面的rman操作的错误缘由，这个是因为小鱼只是restore database，并没有利用备份或者重建控制文件，此时oracle会默认认为所有的联机日子都存在，才报出上面的错误信息。
此时虽然出现上面的日志文件丢失，但是并不影响这个恢复，对应的alert日志，可以看出其中利用归档日志恢复的信息。
Mon Mar 18 04:53:37 EDT 2013
alter database recover datafile list clear
Mon Mar 18 04:53:37 EDT 2013
Completed: alter database recover datafile list clear
Mon Mar 18 04:53:37 EDT 2013
alter database recover datafile list
1 , 2 , 3 , 4 , 5
Completed: alter database recover datafile list
1 , 2 , 3 , 4 , 5
Mon Mar 18 04:53:37 EDT 2013
alter database recover if needed
start until change 1095977
Media Recovery Start
ORA-279 signalled during: alter database recover if needed
start until change 1095977
...
Mon Mar 18 04:53:40 EDT 2013
Archivelog restore complete. Elapsed time: 0:00:00
Archivelog restore complete. Elapsed time: 0:00:01
Mon Mar 18 04:53:40 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219'
Mon Mar 18 04:53:40 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_2.311.810363219'...
Mon Mar 18 04:53:41 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219'
Mon Mar 18 04:53:41 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_2.323.810363219'...
Mon Mar 18 04:53:42 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707'
Mon Mar 18 04:53:42 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_3.299.810362707'...
Mon Mar 18 04:53:42 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707'
Mon Mar 18 04:53:42 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707
ORA-279 signalled during: alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_2_seq_3.295.810362707'...
Mon Mar 18 04:53:43 EDT 2013
alter database recover logfile '+ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717'
Mon Mar 18 04:53:43 EDT 2013
Media Recovery Log +ARCH/xiaoyu/archivelog/2013_03_18/thread_1_seq_4.258.810362717
然后open resetlogs打开数据库即可。
RMAN> alter database open resetlogs;
database opened