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才成。

转贴: http://archive.cnblogs.com/a/1860583/