oracle dg RMAN-600; ORA-19909; ORA-1110; ORA-283

MRP Recovery Failed With ORA-19909 [ID 554358.1]

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

  修改时间 13-JUL-2009     类型 PROBLEM     状态 PUBLISHED   

In this Document
  Symptoms
  Changes
  Cause
  Solution
  References



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



Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3
This problem can occur on any platform.

Symptoms
Physical Standby Database Setup.
The Standby database has been activated (open read/write, resetlogs done), then using Flashback to recover it back to Physical Standby Status. During flashback, it could not recover due to a corrupted archive log.

After Restore backup past that corrupted Point, MRP will get this Error:

ERROR
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/oracle/oradata/PROD/oradg07/PROD_system01_4096m'


Changes
The Standby Database has been activated, then flashback to be Physical Standby again.
Cause
This is caused by Bug 6035495 ORA-19909 during MRP / RMAN-600 on resync
Fixed-Releases: 10.2.0.4, 11.1.0.0
Details:
ORA-19909 during MRP or RMAN-600 (8201) during RMAN resync can occur.
MRP encounter same error and standby has resetlogs done

The Problem here is the Primary Database has only 1 incarnation:

    RMAN> list incarnation of database;
        
    List of Database Incarnations
    DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
    ------- ------- -------- ---------------- --- ---------- ----------
    1       1       PROD     554405896        CURRENT 1          03-MAY-2007 15:52:40
While the Standby Database has 2 Incarnations due to Activation:

    rman > list incarnation of database;
   
    List of Database Incarnations
    DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
    ------- ------- -------- ---------------- --- ---------- ----------
    1       1       LIVE     554405896        PARENT  1          03-MAY-07
    2       2       PROD     554405896        CURRENT 1858780073 14-FEB-08
The CURRENT Incarnation on Standby Database is 2 which is different from Primary Database Incarnation 1. That is why ORA-19909 reported when recovery is done.

The incarnation is recorded in Datafile Header, so simply recreating the Standby Controlfile will not help.

Solution
The Solution is to find out the CURRENT Incarnation from the Primary Database, reset the Standby Database Incarnation to match the Primary Database using rman command:
        reset database to incarnation
then perform Recovery.

In this sample:
Primary Database Incarnation is 1
Standby Database Incarnation is 2

On the Standby Site:

$ rman target=/
rman > reset database to incarnation 1
rman > exit

$sqlplus / as sysdba
SQL> recover standby database;
- supply archive log manually if the sequence prompted is not the right one
- type "CANCEL" after few logs applied
- start managed recovery
SQL> recover managed standby database disconnect;

Check alert log, it should continue Managed Recovery now.

References
BUG:6035495 - ORA-19909 ATAFILE 1 BELONGS TO AN ORPHAN INCARNATION IN STANDBY

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


相关的



--------------------------------------------------------------------------------
产品
--------------------------------------------------------------------------------

?Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
关键字
--------------------------------------------------------------------------------
RESETLOGS; PHYSICAL STANDBY; ORPHAN
错误
--------------------------------------------------------------------------------
RMAN-600; ORA-19909; ORA-1110; ORA-283

---

作者: oldunix    时间: 2011-3-20 21:45

Effect of doing PITR (point in time recovery) / Flashback on PRIMARY when Physical Standby in place ORA-19906 ORA-19909 ORA-01110 [ID 824213.1]

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

  修改时间 22-JUN-2009     类型 PROBLEM     状态 PUBLISHED   

In this Document
  Symptoms
  Cause
  Solution



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



Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.4
This problem can occur on any platform.

Symptoms
Media recovery process (MRP) in Physical standby database terminates with the below errors after PITR or Flashback done on PRIMARY database

RFS[4]: Incarnation entry added for Branch(resetlogs_id): 686768021 (prim)
Wed May 13 16:54:17 2009
Setting recovery target incarnation to 2
Wed May 13 16:54:22 2009
MRP0: Incarnation has changed! Retry recovery...
Wed May 13 16:54:22 2009
Errors in file /u01/prim/bdump/prim_mrp0_1814.trc:
ORA-19906: recovery target incarnation changed during recovery
Recovery interrupted!
Wed May 13 16:54:23 2009
Errors in file /u01/prim/bdump/prim_mrp0_1814.trc:
ORA-19906: recovery target incarnation changed during recovery
Wed May 13 16:54:43 2009
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 908075) is orphaned on incarnation#=1
MRP0: Background Media Recovery terminated with error 19909
Wed May 13 16:54:43 2009
Errors in file /u01/prim/bdump/prim_mrp0_1814.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/u01/prim/data/system01.dbf'
Cause
PRIMARY database was opened with RESETLOGS after the PITR or FLASHBACK database that makes the database incarnation to be different between PRIMARY and STANDBY.

Solution
Flashback Vs PITR

Flashback database is feature of Oracle 10g that helps to rewind the database to a previous state using the flashback logs [Moving backwards ] .

PITR is the traditional way of restore and recover of database to a point in time using the backups. [ Moving forward ]

PITR on PRIMARY

During PITR -Point in Time Recovery even if you have enabled FLASHBACK, PRIMARY datafiles are restored and recovered and database is opened with Resetlogs. This cause the incarnation of Primary and Standby are not identical.

The solution is to recreate the standby database.

Flashback on PRIMARY

If FLASHBACK is enabled on standby database and standby applied redo data past the new resetlogs SCN then Flashback the standby database to the SCN same as PRIMARY and restart the Media recovery process in standby.

If FLASHBACK is NOT enabled on standby database and standby applied redo data past the new resetlogs SCN then recreate the standby database.

References
Oracle® Data Guard, Concepts and Administration, 10g Release 2 (10.2), B14239-05
Chapter 12.5 Using Flashback Database After Issuing an Open Resetlogs Statement

Conclusion

Its advisable to enable flashback on both PRIMARY and STANDBY

Use PITR as a last option in case you cannot flashback the PRIMARY database, since it requires the standby to be recreated.


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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/235507/viewspace-1324143/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/235507/viewspace-1324143/