之前用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才成。
