Recover through incarnations: RMAN-20208

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

RMAN> run{

2>set until scn44712912;

3>restoredatabase;

4> recover database;

5>alterdatabaseopen resetlogs;

6> }

 

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

executing command:SET until clause

RMAN-00571:===========================================================

RMAN-00569:=============== ERROR MESSAGE STACK FOLLOWS===============

RMAN-00571:===========================================================

RMAN-03002: failure ofset command at10/25/201015:10:03

RMAN-20208: UNTIL CHANGE is before RESETLOGS change

 

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

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

RMAN> list incarnation;

ListofDatabase Incarnations

DBKey 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      CURRENT44712913  22-OCT-10

 

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

RMAN> resetdatabaseto incarnation2;

database resetto incarnation2

 

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

RMAN> run{

2> set until scn44712912;

3> restoredatabase;

4> recover database;

5> alterdatabaseopen resetlogs;

6> }

 

executing command:SET until clause

 

Startingrestore at25-OCT-10

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=539 devtype=DISK

 

channel ORA_DISK_1: starting datafile backupsetrestore

channel ORA_DISK_1: specifying datafile(s)torestorefrombackupset

restoring datafile00001to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/SYSTEM01.DBF

restoring datafile00002to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/UNDOTBS01.DBF

restoring datafile00003to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/SYSAUX01.DBF

restoring datafile00004to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/USERS01.DBF

restoring datafile00005to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/EXAMPLE01.DBF

restoring datafile00006to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/XXX001.DBF

restoring datafile00007to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/XXX002.DBF

restoring datafile00008to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/XXX003.DBF

restoring datafile00009to D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/XXX004.DBF

channel ORA_DISK_1: readingfrombackup piece D:/BACKUP/06LQGQTM_1_1

channel ORA_DISK_1: restoredbackup piece1

piece handle=D:/BACKUP/06LQGQTM_1_1 tag=TAG20101015T123149

channel ORA_DISK_1:restore complete, elapsed time:00:12:26

Finishedrestore at25-OCT-10

 

Starting recover at25-OCT-10

using channel ORA_DISK_1

 

starting media recovery

 

archivelog thread1 sequence7180is alreadyondiskasfile D:/ORACLE/PRODUCT/10.2.0/FLASH_RECOVERY_AREA/ORCL/ARCHIVEL

OG/2010_10_15/O1_MF_1_7180_6CHXFG68_.ARC

archivelog 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 at25-OCT-10

 

database opened

大功告成！

 

【Sum-up】

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

 

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