ORA-01152错误的理解

最近做生产环境的异机恢复演练，用NBU做的备份，偶尔会报ORA-1152错误，

restore database 成功

recover database报：

ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/../../raw12' 。

我查了发现控制文件的scn比system表空间数据文件的SCN要大。

根据网上说法，使用隐含参数试图强行打开数据库，失败，报ORA-00600错误。为此，希望各位兄弟不要抱有侥幸心理，数据真要恢复的话这可是要命的。

首先，说说我对这个错误发生的理解。从NBU的备份脚本说起。
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
BACKUP
    $BACKUP_TYPE
    SKIP INACCESSIBLE
    TAG hot_db_bk_level0
    FILESPERSET 5
    # 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';
BACKUP
   filesperset 20
   FORMAT 'al_%s_%p_%t'
   ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;}
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
BACKUP
    # recommended format
    FORMAT 'cntrl_%s_%p_%t'
    CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
}
红色标注，备份步骤很清楚：1数据文件

                                                     2切换一次日志

                                                     3备份归档

                                                     4最后备份控制文件。

在大多数测试环境，这样的备份恢复不会有问题。因为，步骤2完成后，备份归档，首先测试库可能很小，归档日志不是很多（备份较快）。其次，在备份归档的时候，未必发生日志组写满，自动切换的情况。这样，控制文件、数据文件、以及日志文件，可以确定是干净的一致的。

而在这次做的备份，可能很不巧，在步骤三的时候，耗时比较长（一天的生产数据，日志量较大），备份期间，可能一个日志文件写满，自动发生了切换，但是并没有被归档。而此时归档的日志正好备份完毕，rman直接接着备份控制文件。造成我recover动作完不成，且不能resetlogs打开。（此处我的理解比较含糊，不知是否正确，请思路清楚的兄弟指点，呵呵）

我采用备份步骤:

先做一个alter system checkpoint,做完全检查点，确保所有日志被应用到数据文件。

1 backup database;

2:切换一次日志；

3：备份归档日志并删除已备份的日志（大库可能比较耗时）。

4：再切换一次日志，并备份那一个归档日志；

5：备份控制文件；

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7969839/viewspace-678185/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7969839/viewspace-678185/