Recover through incarnations: RMAN-20208

之前用RMAN做过一个数据库的全备，后来发现数据库mess up了，想要恢复到之前做备份的那个状态，这个用RMAN很好办，

RMAN> run{
2> set until scn 44712912;
3> restore database;
4> recover database;
5> alter database open resetlogs;
6> }

不过杯具的是，在resetlogs之后没有再做一次全备。这样在数据库run了一段时间后，发现还是要回到当初状态比较好。寻思着不如再回到从前吧，尝试重复执行上面的这段脚本，却得到如下错误，

executing command: SET until clause
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of set command at 10/25/2010 15:10:03
RMAN-20208: UNTIL CHANGE is before RESETLOGS change

突然意识到，这应该是在resetlogs之后，数据库进入了一个新的incarnation, 因此用上个incarnation的备份来恢复貌似不行了。不过文档上说得请清楚楚，10g加强了这方面的功能，即使resetlogs了，还是可以用之前的备份来恢复数据库的，但是为啥这样重复执行脚本失败了呢？莫非需要穿越到上一次“梦境”中 （想起了盗梦空间 ）吗？

通过 RMAN 的 LIST INCARNATION 命令可以看到当前数据库共有几层"梦境“...

RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       ORCL     1257481935       PARENT  1          29-OCT-05
2       2       ORCL     1257481935       PARENT  518852     14-SEP-10
3       3       ORCL     1257481935       CURRENT 44712913   22-OCT-10

根据reset scn， 可以看到上一次备份实在incarnation 2中做的，尝试把数据库穿越回上一个incarnation中，

RMAN> reset database to incarnation 2;

database reset to incarnation 2

接下来再次尝试用之前的脚本来恢复数据库，

RMAN> run{
2>  set until scn 44712912;
3>  restore database;
4>  recover database;
5>  alter database open resetlogs;
6>  }

executing command: SET until clause

Starting restore at 25-OCT-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=539 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
restoring datafile 00002 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
restoring datafile 00003 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
restoring datafile 00004 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
restoring datafile 00005 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
restoring datafile 00006 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\XXX001.DBF
restoring datafile 00007 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\XXX002.DBF
restoring datafile 00008 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\XXX003.DBF
restoring datafile 00009 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\XXX004.DBF
channel ORA_DISK_1: reading from backup piece D:\BACKUP\06LQGQTM_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=D:\BACKUP\06LQGQTM_1_1 tag=TAG20101015T123149
channel ORA_DISK_1: restore complete, elapsed time: 00:12:26
Finished restore at 25-OCT-10

Starting recover at 25-OCT-10
using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 7180 is already on disk as file D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVEL
OG\2010_10_15\O1_MF_1_7180_6CHXFG68_.ARC
archive log filename=D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_10_15\O1_MF_1_7180_6CHXFG68_.ARC
thread=1 sequence=7180
media recovery complete, elapsed time: 00:00:02
Finished recover at 25-OCT-10

database opened

大功告成！

【Sum-up】

看来虽然10g支持用跨incarnation的备份来恢复数据库，还是需要事先讲数据库set到相应的incarnation才成。