Restarting Fast Start FailOver with ORA-16817 (Doc ID 989157.1)

3380阅读 0评论2015-05-07 摸_摸
分类:Oracle

Restarting Fast Start FailOver (FSFO) after datafile recover fails with ORA-16817 (Doc ID 989157.1)

APPLIES TO:

Oracle Server - Enterprise Edition - Version: 10.2.0.4 - Release: 10.2
Information in this document applies to any platform.

SYMPTOMS

A datafile was restored and recovered on a standby database.

Enabling the Fast_Start Failover afterwards fails with errors :

ORA-16817: unsynchronized Fast-Start Failover configuration
ORA-16819: Fast-Start Failover observer not started

The Primary DRC-logfile showed :

DG 2010-01-14-10:30:56 0 2 0 INSV: Received message for inter-instance publication
DG 2010-01-14-10:30:56 0 2 0 req_id 1.1.706433165, opcode MON_VERIFY, phase BEGIN, flags 5
DG 2010-01-14-10:30:57 0 2 0 RSM0: HEALTH CHECK WARNING: ORA-16817: unsynchronized Fast-Start Failover configuration
DG 2010-01-14-10:30:57 0 2 0 RSM0: HEALTH CHECK WARNING: ORA-16819: Fast-Start Failover observer not started


CAUSE

On the Standby database the FSFP-process was hanging due to unknown cause.

The DRC-logfile on the Standby showed gaps in the tracefile like :

DG 2010-01-12-12:15:36 1010000 4 707685808 DMON: CTL_GET_STATUS forwarded to site nifis for processing
DG 2010-01-12-12:15:36 1010000 4 707685808 DMON: CTL_GET_STATUS operation completed
            <<<<<----- a whole day is missing
DG 2010-01-14-10:24:27 0 2 706433095 DMON: Entered rfm_get_chief_lock() for MON_VERIFY, reason 0
DG 2010-01-14-10:24:27 0 2 706433095 DMON: chief lock convert for client healthcheck

which is strange as regular updates per every minute are expected.

The last tracefile of the FSFP process was also old, and not matching the current attempts to enable FSFO.

SOLUTION

Restarting the Standby Istance resolved the problem
上一篇:Troubleshooting Guide ORA-3136 (Doc ID 465043.1)
下一篇:12c Dataguard Switchover Best Practices using DGMGRL