Why bother implementing the Oracle Data Guard Broker? The short answer is that it handles the heavy lifting of management, monitoring, and recovery for you.
In this post, I’ll share a scenario from a recent test system startup where the Broker proved its worth by automatically resolving common standby inconsistencies.
1. The Scenario: Startup Errors on the Standby
After our test system had been shut down, we encountered a standard roadblock during the initial startup process.
Encountering ORA-10458 and ORA-01196
When attempting a normal STARTUP on the standby instance, the database failed to open, throwing errors related to media recovery:
[oracle@ol7-121-dg2 ~]$ sqlplus / as sysdba SQL> startup; ORACLE instance started. Database mounted. ORA-10458: standby database requires recovery ORA-01196: file 1 is inconsistent due to a failed media recovery session ORA-01110: data file 1: '/u01/oradata/CDB1_STBY/datafile/o1_mf_system_h1x6ofd1_.dbf'
At this stage, the standby is mounted but inconsistent. Manual resolution would typically require identifying the last applied archive log and starting the recovery process manually.
2. Resolving Inconsistency via Data Guard Broker
Instead of manual intervention, we let the Data Guard Broker handle the synchronization.
Moving to a Mounted State
First, we shut down the idle instance and restarted it in a MOUNT state to allow the Broker to communicate with the primary:
SQL> shutdown immediate; SQL> startup mount; ORACLE instance started. Database mounted. SQL> exit
Checking Status with DGMGRL
Once the instance was mounted, we logged into the Data Guard Manager (DGMGRL). Note that the Broker automatically identified the "Apply-On" intended state and resumed recovery without any extra commands:
[oracle@ol7-121-dg2 ~]$ dgmgrl / DGMGRL> show configuration Configuration - my_dg_config Protection Mode: MaxPerformance Members: cdb1 - Primary database cdb1_stby - Physical standby database Configuration Status: SUCCESS
Checking the standby database specifically showed that the Transport Lag was already at 0 seconds:
DGMGRL> show database cdb1_stby Database - cdb1_stby Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds Database Status: SUCCESS
3. Transitioning to Active Data Guard
With the recovery process successfully managed by the Broker, we can easily transition the standby into Active Data Guard mode (Read-Only with Apply).
Enabling Read-Only Access
Now that the files are consistent, we can open the database:
SQL> alter database open read only; Database altered.
Final Status Verification
Returning to DGMGRL, we can see that Real Time Query is now ON, and the Broker is maintaining a SUCCESS status while applying changes in real-time:
DGMGRL> show database cdb1_stby Database - cdb1_stby Role: PHYSICAL STANDBY Intended State: APPLY-ON Apply Lag: 0 seconds Average Apply Rate: 301.00 KByte/s Real Time Query: ON Database Status: SUCCESS
Conclusion
The Oracle Data Guard Broker simplifies what would otherwise be a manual, multi-step recovery process into a single-pane-of-glass management experience. By automatically starting the recovery and managing the intended state of the standby, it ensures that your environment stays synchronized with minimal effort.
Oracle Database Consulting Services
Ready to optimize your Oracle Database for the future?
.svg){kind=small}
.svg){kind=small}