5 Replies Latest reply: Dec 31, 2012 7:34 AM by AlexAntonyArokiaraj RSS

    ORA-19909: datafile 1 belongs to an orphan incarnation

    AlexAntonyArokiaraj
      Hi,

      I have a Primary database emadb and Physical Standby Database emadbdg.

      This is the error when I am starting the Managed Recovery Process on the standby database.
      Managed Standby Recovery not using Real Time Apply
      Slave exiting with ORA-19909 exception
      Errors in file /opt/app/oracle/diag/rdbms/emadbdg/emadbdg/trace/emadbdg_pr00_24135.trc:
      ORA-19909: datafile 1 belongs to an orphan incarnation
      ORA-01110: data file 1: '/opt/app/oracle/oradata/emadbdg/system01.dbf'
      I performed an incremental backup of the Physical Standby Database using RMAN and now the archive logs are not getting applied.

      The Archive Logs are not getting applied on the Physical Standby
      SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
      
      no rows selected
      
      SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
      
         THREAD# MAX(SEQUENCE#)
      ---------- --------------
            1            82
        • 1. Re: ORA-19909: datafile 1 belongs to an orphan incarnation
          mseberg
          Hello;

          Once you use resetlog on a database it belongs to a new incarnation, which means the backup of an earlier incarnation cannot be used.

          If you every recover your database using resetlogs you should take full backup of your database immediately.

          You are probably familar with this command :


          RMAN> LIST INCARNATION OF DATABASE;


          Query V$DATAFILE and V$DATAFILE_HEADER and compare these with V$DATABASE.

          Look for the CHECKPOINT_CHANGE#, CHECKPOINT_TIME columns and compare them.
          SELECT CHECKPOINT_CHANGE#,CHECKPOINT_TIME FROM V$DATAFILE;
           
          SELECT CHECKPOINT_CHANGE#,CHECKPOINT_TIME FROM V$DATAFILE_HEADER;
          There's an RMAN Thread that may help :

          rman recovery ERROR

          Until you have a standby without issue "Apply" is not an option.


          Best Regards

          mseberg



          19909, 00000, <font color="red">"datafile %s belongs to an orphan incarnation"</font></br></br>
          <font color="darkgreen"> *Cause: Either the specified datafile was restored from a backup that was</font></br>
          <font color="darkgreen"> taken during a period of time that has already been discarded by</font><br>
          <font color="darkgreen"> a RESETLOGS operation, or Oracle cannot identify which database</font></br>
          <font color="darkgreen"> incarnation the file belongs to. The alert log contains more</font></br>
          <font color="darkgreen"> information.</font></br></br>
          <font color="darkgreen"> *Action: Restore a backup of this file that belongs to either the current</font></br>
          <font color="darkgreen"> or a prior incarnation of the database. If you are using RMAN</font></br>
          <font color="darkgreen"> to restore, RMAN will automatically select a correct backup.</font>


          Edited by: mseberg on Dec 30, 2012 10:11 AM
          • 2. Re: ORA-19909: datafile 1 belongs to an orphan incarnation
            AlexAntonyArokiaraj
            Thanks for your reply.

            Primary Database Incarnation List
            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       EMADB    944868625        PARENT  1          03-SEP-12
            2       2       EMADB    944868625        CURRENT 100260851  20-DEC-12
            Standby Database Incarnation list
            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       EMADB    944868625        PARENT  1          03-SEP-12
            2       2       EMADB    944868625        CURRENT 100260851  20-DEC-12
            The Incarnation was same on both the database. I read from the Oracle website that i need to back up the datafile % as reported and restore it in standby. I performed the restore of all datafiles in standby and the managed Recovery Process has started. Can you please advise, if this is a wrong approach ?


            However, The problem is on Standby Database, the archive logs are not applied

            SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
            
            no rows selected
            
            SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
            
               THREAD# MAX(SEQUENCE#)
            ---------- --------------
                  1            88
            • 3. Re: ORA-19909: datafile 1 belongs to an orphan incarnation
              CKPT
              You have not posted requested information by Mseberg, Provide output of v$datafile and v$datafile_header.
              Also post the content of /opt/app/oracle/diag/rdbms/emadbdg/emadbdg/trace/emadbdg_pr00_24135.trc
              • 4. Re: ORA-19909: datafile 1 belongs to an orphan incarnation
                AlexAntonyArokiaraj
                Hi CKPT,

                The issue is cleared. Thanks for your support
                • 5. Re: ORA-19909: datafile 1 belongs to an orphan incarnation
                  CKPT
                  Alex Antony Arokiaraj wrote:
                  Hi CKPT,

                  The issue is cleared. Thanks for your support
                  Can you please share your knowledge how this issue been resolved and where was the problem ? and dont forget to close the thread as answered,Keep the forum clean.

                  Thanks.