在搭建dg的时候,使用主库的全备在备库做恢复,第一次恢复完以后出现了gap,然后我就想使用最新的备份再恢复一次数据,于是出现了如下的问题:
错误如下: [size=1em]1
2
3
4
5
6
7
8
9
| RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/25/2015 09:56:55
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
|
查看datafile 1 的备份信息,可以清晰的看到备份文件正常。 1
| RMAN> list backup of datafile 1;
|
然后检查了一下这个:
主备库对比了一下,发现备库比主库多了一个2015-03-24的记录 而且备库的状态为current的日期是2010-07-07。
然后执行如下语句: 1
| RMAN> reset database to incarnation 2;
|
然后继续恢复,一切正常。
然后我回忆了一下这个时间点对备库的操作,日志记录如下: [size=1em]1
2
3
4
5
6
| Resetting standby activation ID 607536602 (0x243645da)
Completed: alter database recover managed standby database finish force
Tue Mar 24 16:14:46 CST 2015
alter database commit to switchover to primary
Tue Mar 24 16:14:46 CST 2015
ALTER DATABASE SWITCHOVER TO PRIMARY
|
因为正好在这个点我把备库强制切换过作为主库,所以出现了这样的情况。
然后查询了一下资料,原来是因为resetlogs以后,重置scn以后,数据库实体就会发生变化,也就会出现使用实体编号是以前的备份无法完成恢复,需要将实体编号改会跟主库一致的情况就OK了。
|