Scribd
Upload
61 views3 pages

Dataguard Broker Report

The document reports on testing of Oracle Dataguard Broker configuration and behavior. It was found that the Dataguard Broker incorrectly reported issues like threshold exceedances and disconnects even when checks showed the primary and standby databases were in sync. It was determined the Broker is too sensitive for wide area network replication and direct SQL checks are more reliable.

Uploaded by

kwakutse20
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
61 views3 pages

Dataguard Broker Report

The document reports on testing of Oracle Dataguard Broker configuration and behavior. It was found that the Dataguard Broker incorrectly reported issues like threshold exceedances and disconnects even when checks showed the primary and standby databases were in sync. It was determined the Broker is too sensitive for wide area network replication and direct SQL checks are more reliable.

Uploaded by

kwakutse20
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Report on Dataguard Broker Test

carried out in

STL

At

PRODUCTION AND DR SITES

Document No. DG_BROKER, Version 1.0 dated 9th September 2022

CONFIDENTIAL

Super Tech (STL) Ltd.,

226 Osibisa Close, Airport West,

P.O. Box KIA 30408, Accra, Ghana

Tel: +233-302-782646 / 7

Fax: +233-302-769622
OBJECTIVE

The objective of this test was to

1. Install and confirm the configuration of Oracle Dataguard (DG) broker


2. Verify the behaviour of Dataguard broker in managing standby databases.

METHODOLGY

Two (2) single instance oracle 19c databases on ASM were installed in a test production and DR
environments

Dataguard was then configured between production and standby databases, to facilitate replication
between the two database instances. Checks were done to confirm that archivelogs were being
applied to the standby database in a timely manner.

Dataguard broker was enabled on both production and standby databases.

We then proceeded to configure dataguard broker to manage the standby database.

FINDINGS

After extensive testing of the dataguard broker, we found the following

1. The dataguard broker was always reporting of ARCHIVELOG apply lag threshold being
exceeded even though the apply lag threshold property was set to 0. Setting the threshold to
0 means it is disabled, hence, DG broker was not supposed to check any threshold.

Database Warning(s):
ORA-16853: apply lag has exceeded specified threshold
ORA-16855: transport lag has exceeded specified threshold
ORA-16857: member disconnected from redo source for longer
than specified threshold

A check from both production and standby databases using sql commands showed that the
primary database was in sync with the standby database. Hence, the warning was a false
negative.

2. On a number of occasions, the DG broker lost connection to standby database.

Database Status:
DGM-17016: failed to retrieve status for database "DRTEST2"
ORA-16662: network timeout when contacting a member

This will mean that when dataguard broker is needed to do failover or bring up the standby
database for testing, it will not be usable.
However using sql commands to check if the standby was in sync with production showed
that Production and standby were in sync and could not support what dataguard broker was
reporting.

3. A check in the alert log of standby database also showed

TNS-12535: TNS:operation timed out


ns secondary err code: 12560
nt main err code: 505

TNS-00505: Operation timed out


nt secondary err code: 110
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.251.88)
(PORT=23752))
2022-09-06T19:36:39.272589+00:00
rfs (PID:10326): Possible network disconnect with primary
database
2022-09-06T20:08:44.377326+00:00

However checks with sql commands also showed that production and standby databases
were in sync

Conclusion

Dataguard broker always reported of archive apply lag, transport lag thresholds being
exceeded and disconnects from standby database even though checks with sql commands
did not support this

It appears that it will be a good tool for working on a local-area-network (LAN), where
fleeting connectivity interruptions are minimal. However, over a wide-area-network (WAN),
as is the case for the replication link, the tool appears to be over-sensitive. It also does not
recover well from any disburses.

We will therefore highly recommend that GCB stick with the recommendation of the Oracle
implementation team, who advised against using DG Broker.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy