Get the App
SLTechnology News&Howtos  ›  Database  › 

12cR2 RAC+RAC+ADG ORA-16854

Shulou Source: shulou.com Published: 2022-06-01 14:32:54 11月15日 Update

Recently, a set of RAC+RAC+ADG+BROKER production system has been built in a bank, and many pits have been encountered, so I will make a record here. If you have questions, you can leave me a message and discuss learning together.

1. Description of environment

Oralce 12cR2 RAC+RAC ADG broker

2. Similar phenomena

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

##Alarm ORA-16854 Unable to confirm application delay, alarm phenomenon is exactly the same as I encountered.

3. Solution

MOS officials have provided two methods, and the specific situation needs further analysis.

1)It could be a 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 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)rebuild control file

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. Open SR

Friends who have conditions or services can open an SR to clarify the problem.

Tags: Methods phenomena production identical two official situation documents friends conditions environment questions systems banks problems one analysis learning application delay Apple Docker Huawei Linux macOS MariaDB Microsoft MySQL NVidia OPPO Reno MariaDB MySQL macOS vpn Huawei