ORA-19909 datafile 1 belongs to an orphan incarnation

ORA-19909 datafile 1 belongs to an orphan incarnation

Contributed by Martin

Friday, 22 May 2009

Last Updated Friday, 22 May 2009

Managed recovery aborts on a standby database. Messages in the alert log of a standby database such as:Fri May 22

08:00:32 2009

Warning: Recovery target destination is in a sibling branch

of the controlfile checkpoint. Recovery will only recover

changes to datafiles.

Datafile 1 (ckpscn 150505647373) is orphaned on incarnation#=2

MRP0: Background Media Recovery terminated with error 19909

Fri May 22 08:00:32 2009

Errors in file /u01/app/oracle/admin/prod/bdump/prod_mrp0_25696.trc:

ORA-19909: datafile 1 belongs to an orphan incarnation

ORA-01110: data file 1: '+DATA/proddr/datafile/system.322.687442153'

Fri May 22 08:00:32 2009

SUCCESS: diskgroup DATA was dismounted

Fri May 22 08:00:32 2009

Errors in file /u01/app/oracle/admin/prod/bdump/prod_mrp0_25696.trc:

ORA-19909: datafile 1 belongs to an orphan incarnation

ORA-01110: data file 1: '+DATA/proddr/datafile/system.322.687442153'

Fri May 22 08:00:32 2009

MRP0: Background Media Recovery process shutdown (prod)

Media Recovery is aborted, the database won't accept any more archived logs.

Cause & Background information

The standby database has been activated previously but since then reverted back into its standby role. Prior to the

RMAN duplicate operation the "alter system reset control_files scope=spfile sid='*';" has not been executed (i.e. the

control files have not been overwritten).

Analysis

Primary and standby have different incarnations:

Standby:[oracle ~]$ echo $ORACLE_SID

prod

[oracle ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Fri May 22 08:31:51 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: prod (DBID=3925170746, not open)

RMAN> list incarnation of database;

using target database control file instead of recovery catalog

List of Database Incarnations

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

------- ------- -------- ---------------- --- ---------- ----------

1 1 prod 3925170746 PARENT 1 12-MAR-08

2 2 prod 3925170746 PARENT 602821 08-OCT-08

3 3 prod 3925170746 ORPHAN 81184152798 30-APR-09

4 4 prod 3925170746 CURRENT 136113061223 18-MAY-09

RMAN> exit

Primary[oracle ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Fri May 22 09:03:32 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: prod (DBID=3925170746)

RMAN> list incarnation of database;

using target database control file instead of recovery catalog

List of Database Incarnations

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

------- ------- -------- ---------------- --- ---------- ----------

1 1 prod 3925170746 PARENT 1 12-MAR-08

2 2 prod 3925170746 CURRENT 602821 08-OCT-08

RMAN> exit

Recovery Manager complete.

SolutionYou need to reset the standby database's incarnation to match the primary's:

[oracle ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Fri May 22 08:35:57 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: prod (DBID=3925170746, not open)

RMAN> list incarnation of database;

using target database control file instead of recovery catalog

List of Database Incarnations

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

------- ------- -------- ---------------- --- ---------- ----------

1 1 prod 3925170746 PARENT 1 12-MAR-08

2 2 prod 3925170746 PARENT 602821 08-OCT-08

3 3 prod 3925170746 ORPHAN 81184152798 30-APR-09

4 4 prod 3925170746 CURRENT 136113061223 18-MAY-09

RMAN> reset database to incarnation 2;

database reset to incarnation 2

RMAN> exit

Recovery Manager complete.

Now, apply a few logs the old fashioned way:

[oracle ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Fri May 22 08:36:26 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> recover standby database

...

When satisfied that this works (compare the alert log) after 3-4 archived logs, re-enable managed recovery. Switch logs

on the primary and make sure they get applied on the standby.ReferenceMetalink Note 554358.1 - MRP Recovery Failed

With ORA-19909