12cR2 RAC+RAC+ADG ORA-16854

最新推荐文章于 2024-06-26 23:53:45 发布

转载最新推荐文章于 2024-06-26 23:53:45 发布 · 672 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://blog.51cto.com/roidba/2327507

文章标签：

#数据库

近期在银行生产环境中搭建Oracle12cR2RAC+RACADGBroker系统时，遇到ORA-16854应用延迟无法确认的告警。本文详细记录了环境描述、类似现象及两种解决方法：一是调整ApplyLagThreshold参数；二是重建控制文件，附带步骤说明。同时，建议有条件者开启SR进一步明确问题。

   近期在某银行生产搭建了一套RAC+RAC+ADG+BROKER的生产系统，遇到了不少坑，再此做一个记录。大家有疑问，可以给我留言，一起讨论学习。

1、环境描述
Oralce 12cR2 RAC+RAC ADG broker

2、类似现象
DGMGRL> show configuration verbose

Configuration - FSF

Protection Mode: MaxAvailability
Members:
test_a - Primary database
standby_c - Physical standby database
standby_b - Physical standby database
Warning: ORA-16854: apply lag could not be determined
##告警ORA-16854 无法确认应用延迟，告警现象和我遇到的是一模一样的。

3、解决方法
MOS 官方提供了两个方法，具体情况还需要进一步分析
1)有可能是BUG
Workaround: set the ApplyLagThreshold=0 but this means you will not receive notifications of apply lag in Broker for the specified Standby database:

                 dgmgrl> edit database <standby db_unique_name> set property ApplyLagThreshold=0;

Please download and apply existing fix for BUG 28803345 or open SR and request backport of BUG 28803345 to resolve the issue.
2)重建控制文件
To solve this issue, recreate the standby controlfile.

Here steps for how to recreated the standby controlfile:

Steps to recreate a Physical Standby Controlfile (Doc ID 459411.1)

Please note in few cases apply lag in v$dataguard_stats was null in the database and Clearing ORLs in standby helped resolve the NULL value issue.

4、开SR
有条件或者服务的朋友可以开一个SR，明确一下问题。

转载于:https://blog.51cto.com/roidba/2327507