ORA-19906 and ORA-19909 at standby site

刘泽宇

现象：
========
Disclaimer:
NOTE: In the images and/or the document content below, the user information and environment data used represents
fictitious data from the Oracle sample schema(s), Public Documentation delivered with an Oracle database product or
other training material. Any similarity to actual environments, actual persons, living or dead, is purely coincidental and
not intended in any manner.
For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

Primary:
DB Name: SGSOPA

Standby:
DB Unique Name: SGSDGB
========

Redo apply at standby site suddenly failed as shown in the alert.log:


Thu Nov 22 14:40:13 MET 2012
Media Recovery Log < directory >/SGSDGB/arch/SGSDGB_1_699789524_129430.arc[1]  
Thu Nov 22 14:40:26 MET 2012
Media Recovery Waiting for thread 1 sequence 129431 [2]                       
Thu Nov 22 14:44:34 MET 2012
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 24267
RFS[4]: Identified database type as 'physical standby'
RFS[4]: Archived Log: '< directory >/SGSDGB/arch/SGSDGB_1_800028335_10.arc'
RFS[4]: Physical Standby in the future of Branch(resetlogs_id) 800028335
RFS[4]: Standby database SCN: 1746:-485073214  Primary branch SCN: 1746:-486307562
RFS[4]: New Archival REDO Branch(resetlogs_id): 800028335  Prior: 699789524
RFS[4]: Archival Activation ID: 0x5a34242d Current: 0x2f28438f
RFS[4]: Effect of primary database OPEN RESETLOGS
RFS[4]: Managed Standby Recovery process is active
New incarnation branch detected in ArchiveLog, filename < directory >/SGSDGB/arch/SGSDGB_1_800028335_10.arc [3]
Inspection of file changed rdi from 1 to 2
Setting recovery target incarnation to 2
Thu Nov 22 14:44:37 MET 2012
MRP0: Incarnation has changed! Retry recovery...
Thu Nov 22 14:44:37 MET 2012
Errors in file < directory >/SGSDGB/admin/bdump/sgsdgb_mrp0_20506.trc:
ORA-19906: recovery target incarnation changed during recovery [4]
Recovery interrupted!
Thu Nov 22 14:44:40 MET 2012
Errors in file < directory >/SGSDGB/admin/bdump/sgsdgb_mrp0_20506.trc:
ORA-19906: recovery target incarnation changed during recovery
Thu Nov 22 14:45:00 MET 2012
Managed Standby Recovery not using Real Time Apply
Warning: Recovery target destination is in a sibling branch
of the controlfile checkpoint. Recovery will only recover
changes to datafiles.
Datafile 1 (ckpscn 7502822792898) is orphaned on incarnation#=1
MRP0: Background Media Recovery terminated with error 19909
Thu Nov 22 14:45:00 MET 2012
Errors in file < directory >/SGSDGB/admin/bdump/sgsdgb_mrp0_20506.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation [5]
ORA-01110: data file 1: '< directory >/SGSDGB/data02/system01.dbf'
Thu Nov 22 14:45:00 MET 2012
Errors in file < directory >/SGSDGB/admin/bdump/sgsdgb_mrp0_20506.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '< directory >/SGSDGB/data02/system01.dbf'



From the above:

[1] most recent archive log applied

[2] the next sequence the standby needs to apply

[3] new archivelog name, and new incarnation!!

[4] there's a change of incarnation detected in this new archivelog

[5] Oracle is only reporting the first datafile issue encountered (file#1). All datafiles at this point belong to an orphaned incarnation



改动：
The standby database was opened with resetlogs.  Usually, this occurs as part of a DR test and standby is then flashed back.  

原因：
This occurs because the standby database, for various reasons, is opened with resetlogs and information on that resides in the FRA.  RMAN will implicitly catalog the FRA thus causing information on this "test" incarnation to be inserted into the mounted standby controlfile.  Therefore information on a new incarnation exists.  


处理方法：
To resolve the issue, at the standby site:

Option #1:

Reset the incarnation to the previous incarnation that matches the primary.  For example:

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;
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