ORA-19909: datafile 1 belongs to an orphan incarnation

I got ” ORA-19909: datafile 1 belongs to an orphan incarnation ”  error in Oracle database.

ORA-19909: datafile 1 belongs to an orphan incarnation

Details of error are as follows.

ORA-19909: datafile %s belongs to an orphan incarnation

Cause: Either the specified datafile was restored from a backup that was taken during 
a period of time that has already been discarded by a resetlogs operation, or Oracle cannot
 identify which database incarnation the file belongs to. The alert log contains more information.

Action: Restore a backup of this file that belongs to either the current or a prior 
incarnation of the database. If you are using RMAN to restore, RMAN will automatically
 select a correct backup.

datafile %s belongs to an orphan incarnation

This ORA-19909 error is related with the Either the specified datafile was restored from a backup that was taken during a period of time that has already been discarded by a resetlogs operation, or Oracle cannot identify which database incarnation the file belongs to. The alert log contains more information.

If you got this error on the Standby or Disaster Recovery side, then you need to reset incarnation to the Production’s incarnation.

List incarnation on both sqlplus and RMAN like following.

RMAN> list incarnation of database;


SQL> select INCARNATION#, RESETLOGS_TIME from v$database_incarnation order by RESETLOGS_TIME desc;

INCARNATION# RESETLOGS
------------ ---------
2 24-JUN-19
1 14-JUN-13

SQL>

reset standby database to Production incarnation like following.

RMAN> reset database to incarnation 1;

using target database control file instead of recovery catalog
database reset to incarnation 1

RMAN>

After reset operation, list incarnation again, it will change.

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       DEVECI     229957177        CURRENT 1          14-JUN-13
2       2       DEVECI     229957177        ORPHAN  5993590971744 24-JUN-19

RMAN>

Now you can start the dataguard MRP process as follows.

alter database recover managed standby database disconnect from session;

Second case is as follows.

Duplicate from active is failing with the following error during the recovery  :

RMAN-03002: failure of Duplicate Db command at 07/14/2014 18:31:30
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start until change 10977508941797 using backup controlfile
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: ‘+<asm dg>/<new db name>/datafile/<db file name>’

During the  duplicate from active, after the datafiles are copied, RMAN is building a memory script in order to catalog all the archive log files copied from source to auxiliary site , then it  is cataloging all the files under the diskgroup specified by the FRA (Fast Recovery Area) and then is doing the switch of  all datafiles. An example of the Memory script is :

{
backup as copy reuse
archivelog like "+<asm dg>/.../filename.ext"   auxiliary format  "+<asm dg>" ;
:::::  
Catalog clone start with  "+<diskgroup>";
switch clone datafile all;
}

The  RMAN command “Catalog clone start with  "+<asm dg>" " is  cataloging all the files under the diskgroup specified.  RMAN  is  cataloging all  the archive log files that belong to a database with the same dbid, does not matter if the name of the database is the same or  different.

Now, If the   diskgroup is used for a lot of databases and there are  databases with different name but  same DBID which are generating archive log files, then, RMAN  cataloges  the  archive log files which can have different incarnation.    At the moment that the archive log file is cataloged, the incarnation in the controlfile of auxiliary database  could change  and this prevent that the recovery of this  database can be completed and the entire duplicate from active fails.

In  previous version, RMAN tries to catalog all the files under the recovery area only  (” catalog clone recovery area”),  but in version 11.2.0.3, the command was changed to catalog all the files under the location where the archive log files are configured in auxiliary database   ("Catalog clone start with  "+<asm dg>") .

To the question “Why  there are archive log files with the same dbid but different database name in the same diskgroup ?”  The answer is:  because there is an existing restore of the database.  I.e., a previous attempt failed.  Previous running database which is being cloned again.

You have the following options :

Option 1:  In order to complete the duplicate manually, the steps are :
======

*  The incarnation in the controlfile has to be changed.
*  Complete the recovery.
*  Recreate the controlfile and specify the new location of the redo log files.
*  Open the database.

For details, see:

Manual Completion of a Failed RMAN Backup based Duplicate (Note 360962.1)

Option 2:     If log_archive_dest_1 is not set, change the location of the FRA specifying a diskgroup where there are no databases with the same DBID exists.
======

* The value for db_recovery_file_dest  has to be a filesystem or only the ASM diskgroup name.  Do not specify a directory within the diskgroup.  Doing so will result in error the database is mounted.  

Option 3:  If log_archive_dest_1 is specified, ensure there are no files of database with the same DBID in that location.  In this case, FRA can be set to a diskgroup where other databases exist.
======

For example :

* In the parameter file of auxiliary appears :

*.db_recovery_file_dest='+<asm dg>'
*.log_archive_dest_1='LOCATION=+<asm dg>/<new db name'

when RMAN is duplicating the database, the  memory script will show the archive log files to be  cataloged.  For example:

contents of Memory Script:
{
  backup as copy reuse
  archivelog like  "+<asm dg>/<db name>/archivelog/<date>/thread_1_seq_1742.2339.853243229" auxiliary format
"+<asm dg>/temp/<filename>"   ;
  catalog clone archivelog  "+<asm_dg>/<new db name>/<filename>";   <======== is cataloging only the archive log file copied
  switch clone datafile all;
}

Option 4:  Change the dbid of the databases that have  the same dbid of source db.   NID utility can be used to change the DBID of the database.
======

Do you want to learn Oracle Database for Beginners, then read the following articles.