DATAGUARD BROKER (DGBROKER)
Dgbroker: Oracle Data Guard Broker is a management and automation tool for Oracle Data Guard
configurations. It simplifies the setup, monitoring, and administration of standby databases used for disaster
recovery and high availability.
It provides both a command-line interface (DGMGRL) and GUI-based management through Oracle
Enterprise Manager (OEM) to handle Data Guard tasks more efficiently and with less manual error.
Feature Description
Manages both primary and standby databases from one
Centralized Management
place.
Automated Role Management Easy Switchover/Failover with a single command.
Continuously monitors the Data Guard configuration for
Health Monitoring
issues.
Automatic Failover (Fast-Start
Automatically switches to standby if primary is down.
Failover)
Automates complex tasks like setting parameters and
Reduces Manual Steps
services.
GUI Integration with OEM Full control via Oracle Cloud Control (OEM).
Manages Properties and
Sets and validates database settings for Data Guard.
Parameters
Components of Broker
• DGMGRL: CLI tool to configure/manage
• OEM: GUI for monitoring
• DG_BROKER_CONFIG_FILE1, DG_BROKER_CONFIG_FILE2: Store broker config on disk
STEP 1: Enable Broker Parameters
On Primary :
On Standby:
STEP 2: Login to DGMGRL on primary
STEP 3: Create Primary Configuration
Before adding standby database set empty log_archive_dest_2=’’; on standby
STEP 4: Add Standby to Configuration and enable configuration
STEP 5: Enable Configuration
STEP 6: Verify Configuration
Connection for dgbroker
STEP 7: Add Listener Service (if needed)
On both Primary & Standby:
Edit listener.ora and add services like:
Then restart listener:
lsnrctl reload
lsnrctl status
STEP 8: Set StaticConnectIdentifier for Broker (Important for Switchover/Failover)
On each database (both primary and standby), run this command in DGMGRL:
Once set,
Check using Verbose command Detailed Status of Each Database
Show database verbose prod;
On stadby:
Show database verbose stand;
STEP 9: Validate primary Before Switchover
The output must be seen Ready for switchover:yes
Validate Standby Before Switchover
The output must be seen Ready for switchover:yes
SWITCHOVER
STEP 10: Perform switchover
STEP 11: After Switchover, Verify the configuration
Stand-primary
Prod -physical standby
STEP 12: Once check status at db level old primary (new standby)
STEP 13: Once check status at db level old standby ( new Primary)
STEP 14: Once check perfectly working or not primary and standby by creating table
on new primary
STEP 15: Read from new standby
Reverse switch over for original state
STEP 16: Perform on new standby again back to original primary
STEP 17: check status on standby
check status on primary
FAILOVER :
STEP 18: Before failover simulate the original primary
STEP 19: Check configuration on standby it shows primary database not available
STEP 20: Perform failover on standby side
STEP 21: Check status it is now primary
Now it shows physical standby not available
REINSTATE:
STEP 22: The original primary database can now be configured as a standby. If
flashback database was enabled on the primary database, then this can be done
relatively easily with the following command.
DGMGRL> reinstate database prod;
Now it is physical standby
If flashback database is not enabled, you would have to manually recreate cdb1 as a standby.
The basic process is the reverse of what you did previously.
This is reference image only for manual steps
Our primary is :prod
Our standby is :stand
STEP 23:
Snapshot Standby
Introduced in 11g, snapshot standby allows the standby database to be opened in read-write mode. When
switched back into standby mode, all changes made whilst in read-write mode are lost. This is achieved
using flashback database, but the standby database does not need to have flashback database explicitly
enabled to take advantage of this feature, thought it works just the same if it is.
Connect to the primary (prod) database and convert the standby database (stand) to a snapshot standby.
Perform on primary side
DGMGRL> convert database stand to snapshot standby;
In our Scenario primary as: prod
Standby as :stand
Ref image:
When you are finished with the snapshot standby, convert it back to a standby database.
Snapshot standby →physical standby
DGMGRL> convert database stand to physical standby;
Ref image:
Steps to Change protection mode from Max Performance (ASYNC) to Max
Availability ( SYNC):
STEP 1: Set redo transport mode to SYNC on the standby:
DGMGRL> EDIT DATABASE 'STANDBY' SET PROPERTY 'LogXptMode'='SYNC';
The MaxAvailability mode requires SYNC redo transport to at least one standby. If the standby (stand) is still using
ASYNC, then trying to change the protection mode will fail with an error like
You can confirm afterward using:
DGMGRL> SHOW DATABASE 'stand' 'LogXptMode';
STEP 2: Change to Maximum Availability
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
STEP 3: check configuration
DGMGRL> SHOW CONFIGURATION;
Configuration - dg_config
Protection Mode: MaxAvailability
Members:
prod - Primary database
stand - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
