Chinaunix首页 | 论坛 | 博客
  • 博客访问: 328510
  • 博文数量: 62
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 710
  • 用 户 组: 普通用户
  • 注册时间: 2013-05-14 14:12
个人简介

太懒

文章分类

全部博文(62)

文章存档

2015年(8)

2014年(20)

2013年(34)

我的朋友

分类: Oracle

2015-05-07 11:03:43

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
阅读(3265) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~