一、问题现象

第一轮搭建ADG完成后，fail over dg备库变成测试库给开发应用人员进行测试；

第二轮正式切换之前，重建ADG环境, restore database 正常，recover database 报错。

Thu Oct 28 21:35:11 2021
Warning: Recovery target destination is in a sibling branch of the controlfile checkpoint. 
Recovery will only recover changes to datafiles. 
Datafile 1 (ckpscn 20575410237) is orphaned on incarnation#=2 
MRP0: Detected orphaned datafiles! Recovery will possibly be retried after flashback... 
Errors in file /u01/app/oracle/diag/rdbms/oxxx/oxxxx/trace/oxxxx1\_pr00\_5100.trc: 
ORA-19909: datafile 1 belongs to an orphan incarnation 
ORA-01110: data file 1: '+DATA/oxxx/datafile/system.265.1087143661' 
Managed Standby Recovery not using Real Time Apply 
Recovery Slave PR00 previously exited with exception 19909
Thu Oct 28 21:35:32 2021 MRP0: Background Media Recovery process shutdown (oxxx1)

二、问题排查

2.1 问题原因

报错的场景是说DG recover的时候报错，控制文件"化身"(incarnation )的问题;

场景往往发生在resetlogs后，产生新的版本的化身，但是RMAN的 FRA自动记录了化身并且将这个化身写入了新的控制文件当中，导致你的DG控制文件存在多个不同SCN演进化身的版本；

那么这种情况和我们本次遇到的问题非常的匹配，因为这个新环境DG之前做过一次resetlogs,只要操作一次resetlogs，那么控制文件就会产生一次新的化身（incarnation）；

由于我们没有百分百的清理干净，导致Oracle rman fra 自动将上一次的resetlogs后的化身写入到了控制文件当中，恢复的时候化身版本不对！

2.2 问题处理

This is the primary database's incarnation: 
RMAN> list incarnation of database; 
using target database control file instead of recovery catalog 
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 
------- ------- -------- ---------------- --- ---------- ---------- 
1 1 SGSOPA 791150137 CURRENT 121289826 09-OCT-09 

This is the standby database's incarnation: 
RMAN> list incarnation of database; 
using target database control file instead of recovery catalog 
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time 
------- ------- -------- ---------------- --- ---------- ---------- 
1 1 SGSOPA 791150137 PARENT 121289826 09-OCT-09 
2 2 SGSOPA 791150137 CURRENT 7502821558550 22-NOV-12 
In standby, execute: 

RMAN> reset database to incarnation 1;

解法

RMAN> list incarnation of database; 

RMAN> reset database to incarnation 1;

三、问题学习

参考文章
https://www.cnblogs.com/askscuti/p/10939593.html 
https://www.cnblogs.com/cqubityj/p/3492569.html

3.1 Oracle incarnation是什么？

ORA-19909，incarnation_ORA-19909


其实一张图就能解释问题，如果正常情况数据库一直正常运行，那么就只有一个化身，SCN一直往一个方向走；

但是在某些场景下，DB使用了resetlogs 不完成的恢复时，那么就会产生一个新的化身，因为你的SCN方向以及和完全恢复的方向不同了。

如何查询当前数据库的化身：

select INCARNATION#,RESETLOGS_CHANGE#,RESETLOGS_TIME,STATUS from v$database_incarnation;

3.2 如何避免出现这个问题呢？

那么如何避免可能出现的控制文件化身导致恢复的干扰的情况呢？MOS有方法二，还是上面的同一篇文章。

Option #2:
Clear the FRA information associated with the resetlogs executed against the standby.
1) remove archivelog files and/or controlfile autobackups which were generated by the 
standby when it was activated (opened with resetlogs). 
Leave only the archivelog files received from the primary.
2) consider refreshing standby controlfile from primary to remove unnecessary
 incarnation information from standby controlfile's v$database_incarnation.
3)  start manual recovery, applying the next archivelog from the primary
 site to confirm that recovery will now continue
4)  restart automatic recovery at the standby site

1.将上一次resetlogs库open之后产生的archive log ,log进行删除清理;
2.将上一次resetlogs库open之后产生的控制文件自动备份的文件进行清理;
3.使用主库最新的控制文件对DG库的控制文件进行覆盖；
4.再次进行recover之后，开启MRP进程自动恢复。