Let DataGuard Broker Do ALL The Work

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?