Oracle如何跨越incarnation进行数据恢复

作者介绍：老苏，10余年DBA工作运维经验，擅长Oracle、MySQL、PG、Mongodb数据库运维（如安装迁移，性能优化、故障应急处理等）
公众号：老苏畅谈运维
欢迎关注本人公众号，更多精彩与您分享。

从10g开始，incarnation被引入，每次使用resetlogs打开数据库，就会使incarnation + 1，也就是产生一个新的incarnation。resetlogs命令表示一个数据库逻辑生存期的结束和另一个数据库逻辑生存期的开始，Oracle把这个数据库逻辑生存期称为incarnation，也有人翻译成化身。

上图来源官方文档，其中灰色线是数据库rman恢复之后的运行路径。

当进行不完全恢复后，可能没达到恢复的要求，这个时候数据库已经被resetlogs方式打开过了，如果这个时候又想恢复上一个incarnation的某些数据，在这种场景下就需要进行跨incarnation进行恢复，我们来看一下具体的恢复的过程：
1、查看当前数据库的incarnation

RMAN> list incarnation;


List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBBBED   3361927164       PARENT  2064123    29-MAY-24
2       2       DBBBED   3361927164       PARENT  2086782    31-MAY-24
3       3       DBBBED   3361927164       CURRENT 4955996    30-JUL-24

在list incarnation命令中显示有3个incarnation，且第3条记录的status 字段为CURRENT，表示当前所在的化身。

把数据库的数据文件和日志文件都删除，不要清理控制文件，如果需要重新恢复库至4955996之前的SCN号（如4955990），将会出现什么情况？

RMAN> run{
set until scn 4955990;
restore database;
recover database;
}2> 3> 4> 5> 

executing command: SET until clause

Starting restore at 30-JUL-24
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 07/30/2024 15:36:03
RMAN-20208: UNTIL CHANGE is before RESETLOGS change

如上所示，恢复会报错，提示RMAN-20208，其实提示的也很清楚，就是告诉我们，控制文件里面已经记录过比这个SCN大的resetlogs，需要恢复的SCN不在当前数据库生命周期中。如需恢复，则需要把SCN重置到它所在的生命周期中（4955990应在第2个化身）

RMAN> reset database to incarnation 2;

database reset to incarnation 2

RMAN> list incarnation;


List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBBBED   3361927164       PARENT  2064123    29-MAY-24
2       2       DBBBED   3361927164       CURRENT 2086782    31-MAY-24
3       3       DBBBED   3361927164       ORPHAN  4955996    30-JUL-24

通过reset 命令可以重置数据库的生命周期。在重置后，可以看到第2号记录的STATUS字段调整为CURRENT，这时再进行恢复：

RMAN> run{
set until scn 4955990;
restore database;
recover database;
}2> 3> 4> 5> 

executing command: SET until clause

Starting restore at 30-JUL-24
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /u01/oradata/dbbbed/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/oradata/dbbbed/tbst01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /u01/oradata/dbbbed/szr01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u01/oradata/dbbbed/mssm01.dbf
channel ORA_DISK_1: reading from backup piece /media/backup/backlv0_DBBBED_20240729_1175614789_48_1
channel ORA_DISK_1: piece handle=/media/backup/backlv0_DBBBED_20240729_1175614789_48_1 tag=TAG20240729T153948
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/oradata/dbbbed/system01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/oradata/dbbbed/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/oradata/dbbbed/users01.dbf
channel ORA_DISK_1: restoring datafile 00008 to /u01/oradata/dbbbed/test0529.dbf
channel ORA_DISK_1: reading from backup piece /media/backup/backlv0_DBBBED_20240729_1175614789_47_1
channel ORA_DISK_1: piece handle=/media/backup/backlv0_DBBBED_20240729_1175614789_47_1 tag=TAG20240729T153948
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 30-JUL-24

Starting recover at 30-JUL-24
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 54 is already on disk as file /u01/arch/1_54_1170455884.dbf
archived log for thread 1 with sequence 55 is already on disk as file /u01/arch/1_55_1170455884.dbf
archived log for thread 1 with sequence 56 is already on disk as file /u01/arch/1_56_1170455884.dbf
archived log file name=/u01/arch/1_54_1170455884.dbf thread=1 sequence=54
archived log file name=/u01/arch/1_55_1170455884.dbf thread=1 sequence=55
archived log file name=/u01/arch/1_56_1170455884.dbf thread=1 sequence=56
media recovery complete, elapsed time: 00:00:01
Finished recover at 30-JUL-24

可以看到恢复正常，然后使用open resetlogs打开看看

SQL> alter database open resetlogs;

Database altered.

打开正常。

关注我，学习更多的数据库知识！