Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

ORA-19909 (a failure caused by DataGuard Failover

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

A hospital customer, the core database has two reserve databases. Because I want to use one of the standby hosts for testing, I want to switch the database to read-write mode. In this way, the failover action of preparing the library is involved. This failover is carried out under the condition that another standby library and the main library are still alive.

Faiover is going well. After Failover, I modified several parameters of the database's DG, and thought it was over that day.

On the second day, the customer informed another database that the data was not synchronized. So log in and see the following error in the alarm log

MRP0: Incarnation has changed! Retry recovery...

Errors in file / oradata/u01/app/diag/rdbms/orcldg/orcl/trace/orcl_pr00_3272.trc:

ORA-19906: recovery target incarnation changed during recovery

Managed Standby Recovery not using Real Time Apply

Recovery interrupted!

Recovered data files to a consistent state at change 19274002051

Tue Jun 09 16:37:39 2020

Started logmerger process

Tue Jun 09 16:37:39 2020

Managed Standby Recovery starting Real Time Apply

Warning: Recovery target destination is ina sibling branch

Of the controlfile checkpoint. Recovery will only recover

Changes to datafiles.

Datafile 1 (ckpscn 19274002051) is orphaned on incarnation#=3

MRP0: Detected orphaned datafiles!

Recovery will possibly be retried after flashback...

Errors in file / oradata/u01/app/diag/rdbms/orcldg/orcl/trace/orcl_pr00_27714.trc:

ORA-19909: datafile 1 belongs to an orphan incarnation

ORA-01110: datafile 1:'/ oradata/datafile/system01.dbf'

View incarnation through RMAN

Connected to target database: ORCL (DBID=1385973181)

RMAN > list incarnation

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 ORCL 1385973181 PARENT 1 13-SEP-14

2 2 ORCL 1385973181 PARENT 4733207525 12-FEB-15

3 3 ORCL 1385973181 CURRENT 8619762801 08-JUL-17

4 4 ORCL 1385973181 ORPHAN 19273953428 09-JUN-20

Among them, incarnation 4 was produced by making failover yesterday.

In fact, the solution is relatively simple:

Reset database incarnation to 3

Then open the log application.

Wed Jun 10 11:10:26 2020

RFS [5]: Assigned to RFS process 19310

RFS [5]: Allowing overwrite of partial archivelog for thread 2 sequence 40151

RFS [5]: Opened log for thread 2 sequence 40151 dbid 1385973181 branch 948759254

Completed: alter database recover managed standby database using current logfile disconnect

Archived Log entry 72765 added for thread 2 sequence 40151 rlc 948759254 ID 0x5d2e975e dest 2:

Media Recovery Log / oradata/arch/2_40151_948759254.dbf

Media Recovery Waiting for thread 1 sequence 1748

Archivelog record exists, but no file is found

RFS [5]: Opened log for thread 1 sequence 36160 dbid 1385973181 branch 948759254

Archived Log entry 72766 added for thread 1 sequence 36160 rlc 948759254 ID 0x5d2e975e dest 2:

MRP0: Log being waited on was inappropriate for recovery. Retry recovery...

Errors in file / oradata/u01/app/diag/rdbms/orcldg/orcl/trace/orcl_pr00_19224.trc:

ORA-16426: Recovery requested an incorrect log from which to apply redo data.

Managed Standby Recovery not using Real Time Apply

Wed Jun 10 11:10:34 2020

Recovery interrupted!

Wed Jun 10 11:10:54 2020

Started logmerger process

Wed Jun 10 11:10:55 2020

Managed Standby Recovery starting Real Time Apply

Parallel Media Recovery started with 16 slaves

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Media Recovery Log / oradata/arch/2_40151_948759254.dbf

Media Recovery Log / oradata/arch/1_36160_948759254.dbf

Media Recovery Log / oradata/arch/2_40152_948759254.dbf

Media Recovery Log / oradata/arch/1_36161_948759254.dbf

For this failure, you should modify the DG-related parameters of the master / slave database before doing failover. As a database engineer, you should be more thoughtful.

Fortunately, the scope of influence is small.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report