不完全恢复遭遇ORA-01152的理解，欢迎拍砖

显示全部楼层 · 2013-2-25 14:51:24

最近做生产环境的异机恢复演练，用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：备份控制文件；

千问 · 2013-2-25 14:51:24

不知道我这样理解是不是正确，不是很深刻。如果有那个兄弟可以有重现该报错的方法，请麻烦贴一下。

千问 · 2013-2-25 14:51:24

按照oracle的解释，是数据文件的SCN大于控制文件的SCN造成的，可是我是最后才备份的控制文件，怎么会发生这种情况？

千问 · 2013-2-25 14:51:24

自己顶……

千问 · 2013-2-25 14:51:24

自己再顶……

千问 · 2013-2-25 14:51:24

我查了发现控制文件的scn比system表空间数据文件的SCN要大
这个是正确的因为控制文件最后备份的
我在想是否restore的时候没有成功将system的dbf 成功restore到指定位置
实际在你raw上的是dbf 的scn 是比你恢复回来的control file scn 大的文件?

千问 · 2013-2-25 14:51:24

异机恢复，存储设备上原来是空的，啥都没有，restore回去的东西是唯一的，不存在需要覆盖旧文件的现象。

千问 · 2013-2-25 14:51:24

我查了发现控制文件的scn比system表空间数据文件的SCN要大。
1你是如何发现此情况的? 或者说, 你比较了哪些信息?
2我不清楚你的RECOVER DATABASE 命令是如何写的? 出现这种错误:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/../../raw12' 。
只能说明,当时没有足够的日志供恢复. 也就是, 数据文件的SCN比当前可用的最大SEQ的归档日志里的SCN还大,
所以系统反馈, 备份文件不够老, 因为归档日志比它老.

千问 · 2013-2-25 14:51:24

而在这次做的备份，可能很不巧，在步骤三的时候，耗时比较长（一天的生产数据，日志量较大），备份期间，可能一个日志文件写满，自动发生了切换，但是并没有被归档。而此时归档的日志正好备份完毕，rman直接接着备份控制文件。造成我recover动作完不成，且不能resetlogs打开。（此处我的理解比较含糊，不知是否正确，请思路清楚的兄弟指点，呵呵）
这种说法不成立的, RMAN备份完库以后, 只要备份完之后的最早的归档日志存在, 即可确保数据库恢复时, 所有数据文件
的SCN号能恢复到一致. 也即, 可以OPEN RESETLOGS. 你不妨测试一下, RESTORE 出所有的数据文件后, 在V$DATAFILE_HEADER
里查看它的CHECKPOINT_CHANGE#值, 再和备份后最早的日志文件的NEXT_SCN比较, 后者肯定比前者大, 也就是说,
只需要此归档日志, 就可恢复所有数据文件的模糊性.

千问 · 2013-2-25 14:51:24

再说一句, 楼主, 在RMAN里, 把所有的ARCHIVELOG 列出来, 看看是否丢掉哪个?
list backup of archivelog all by file;