说说碰到这个问题的背景。
使用NBU调脚本对oracle进行备份。脚本如下：
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
$BACKUP_TYPE
SKIP INACCESSIBLE
TAG hot_db_bk_level0
FILESPERSET 1 #（为了模拟大库的长时间备份，将此参数调为1，原因后面解释）
# recommended format
FORMAT 'bk_%s_%p_%t'
DATABASE;
sql 'alter system archive log current';
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
# backup all archive logs
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
filesperset 1
FORMAT 'al_%s_%p_%t'
ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
#
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
# recommended format
FORMAT 'cntrl_%s_%p_%t'
CURRENT CONTROLFILE;
BACKUP FORMAT 'contrl' CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
}
按照常规方法做异机恢复，recover database报错：
Starting recover at 23-MAR-11
starting media recovery
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 2 was not restored from a sufficiently old backup
ORA-01110: data file 2: '/u01/oradata/test/undotbs01.dbf'
released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/23/2011 21:55:47
RMAN-06053: unable to perform. media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 52 lowscn 554211 found to restore
RMAN-06025: no backup of log thread 1 seq 51 lowscn 554193 found to restore
RMAN-06025: no backup of log thread 1 seq 50 lowscn 554178 found to restore
RMAN-06025: no backup of log thread 1 seq 49 lowscn 554176 found to restore
RMAN-06025: no backup of log thread 1 seq 48 lowscn 554173 found to restore
RMAN-06025: no backup of log thread 1 seq 47 lowscn 554170 found to restore
RMAN-06025: no backup of log thread 1 seq 46 lowscn 554151 found to restore
下面说说关于这个报错。按照字面意思，file 2 was not restored from a sufficiently old backup ，查了metalink，说是数据文件的scn比控制文件新造成的。我觉得这个ORACLE官方解释存在错误。也就是报错原因跟数据文件的版本压根没关系，我做了如下验证：
SQL> select max(checkpoint_change#) from v$datafile_header; （数据文件最大的现有SCN）
MAX(CHECKPOINT_CHANGE#)
-----------------------
554055
SQL> select checkpoint_change#,current_scn from v$database (控制文件scn)
CHECKPOINT_CHANGE# CURRENT_SCN
------------------ -----------
554193 0
RMAN> list backup of archivelog all;
List of Backup Sets
===================
………………
61 256.00K SBT_TAPE 00:00:47 23-MAR-11
BP Key: 61 Status: AVAILABLE Compressed: NO Tag: TAG20110323T211447
Handle: al_61_1_746572899 Media:
List of Archived Logs in backup set 61
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 45 554130 23-MAR-11 554151 23-MAR-11
可以看到，备份下来最新的日志，是45号日志组，scn 554130- 554151
总结：数据文件最大scn：554055
控制文件scn：554193。
下面说说我是如何重现这个错的：在备份执行的时候，定时地切换日志，模拟数据库备份时间长，期间发生日志切换的动作。
SQL> alter system switch logfile;
System altered.
SQL> select sequence# from v$log;
SEQUENCE#
----------
50
51
49
SQL> select first_change# from v$log;
FIRST_CHANGE#
-------------
554178
554193
554176
可以看到，日志已经跑到51号了，但RMAN脚本跑起来，只记录开始备份日志开始那个时间点，有那些日志需要备份，而备份日志过程中，产生的新日志，ORACLE根本不管。在这种情况下，做恢复，必然报ORA-1152错。
研究透彻了报错原因，要启动数据库很简单，刚才看到了，备份下来的最新日志：是45号日志组，scn 554130- 554151 。只要指定恢复到scn：554151，就能按常规的resetlogs打开。
验证：
RMAN> run{
2> allocate channel ch00 type 'SBT_TAPE';
3> SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
4> recover database until scn 554151;
5> alter database open resetlogs;
6> release channel ch00;}
allocated channel: ch00
…………
media recovery complete, elapsed time: 00:00:00
Finished recover at 23-MAR-11
database opened
完成。
回头看看报这个错的原因，其实跟NBU的脚本有关。所有备份的数据类型，写在一个RUN块中，造成备份开始（或开始备份归档以后），oracle统计需要备份的日志文件，未将备份过程中产生的日志算进去，造成日志缺失。信息不一致。（这块我不是很确定）。
归根结底，就是备份数据库的时候，库太繁忙（或者备份时间过长），造成日志 切换了。2条思路：1调整备份窗口，空闲时间备份。2我通过以下办法可以解决，由于备份的那个库不算太繁忙（日志切换不快），但备份时间比较长。在第一个 run块后，再加一个单独备份归档的run块：
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
sql 'alter system archive log current';
BACKUP
filesperset 10
FORMAT 'al_%s_%p_%t'
ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
}
由于之前已经把当天大部分日志都备掉了。我这里再备一次，就我备份2小时内发生的日志切换，10个文件一打包，2通道跑，对于不很繁忙的库，相信不会在这期间切日志了。我就不信你丫再报错。
测试：跟先前测试一样，时刻监控rman输出，在第一个run块备份时，多切几次日志。
在第二个run块，不要切日志。（这样配置在不繁忙的库，很难发生日志切换了）
使用第二个run块调的控制文件备份进行恢复。
经测试，这样备份跟小库情况一样，直接resetlogs就可以打开库。库的状态为第二个run块开始执行的状态。
本文转自：http://www.itpub.net/thread-1410747-1-1.html