This post is part of a blog series.

Until now, checking whether a database was ready to switch over or fail over meant running the VALIDATE DATABASE command through DGMGRL: there was no direct SQL alternative, and the VALIDATE DATABASE command isn’t available with other broker interfaces.

In Data Guard 26ai, the V$DG_BROKER_CONFIG view now includes two new columns: SWITCHOVER_READY and FAILOVER_READY. These columns, updated every minute by the Data Guard Broker’s health check, provide the status for switchover and failover readiness.

This means you can now monitor configuration topology, member status, and role change readiness directly with a SQL query, streamlining observability and monitoring through any SQL*Net client, without relying on DGMGRL.

For now, if either column shows “NO”, you still need DGMGRL for detailed diagnostics.

This post is part of a blog series.

Monitoring your Data Guard configuration is essential to ensure your database remains healthy. The Data Guard broker includes a VALIDATE DATABASE command which assesses the system’s health and determines its readiness for switchover or failover.
Up to 21c, this command checks technical readiness for these operations and confirms whether they are likely to succeed. However, some misconfigurations, such as disabled flashback logging or offline PDBs, might not cause immediate failures but still present risks of data loss or other operational issues.
For example, if flashback logging is disabled, a failover would require reinstating the former primary. If there are offline PDBs on the standby database, perhaps because the primary was cloned without copying over the data files, these PDBs would not be available after a failover. This situation could cause data loss. Other issues may not block a switchover, yet still lead to unwanted results.
Oracle Data Guard 26ai introduces strict database validation. This feature marks a database as not ready for switchover or failover if any advanced checks fail.

Strict validation checks include:

• Matching apply properties
• Matching transport properties
• All data files online
• All PDBs online
• Flashback logging and force logging enabled
• Properly configured and cleared log files
• No saved PDB states, which is important to avoid issues with Active Data Guard

To run all these checks at once, use:

This post is part of a blog series.

With release 26ai, generating AWR reports from Active Data Guard standby databases is now simple and direct, without extra configuration required.

Previously, starting in version 12c Release 2, you had to set up DB links and use the Remote Management Framework (RMF) with the DBMS_UMF package to let the primary database collect remote AWR snapshots from standby databases. This process, documented in MOS note 2409808.1 How to Generate AWRs in Active Data Guard Standby Databases (now KB140685), was complex and could lead to non-working state, especially after failovers.

Now, you can generate reports right on the standby database. Because the standby is open read-only, we export snapshots to a dump file, transfer them internally to the primary using Data Guard communication, and import them there for reporting.

This post is part of a blog series.

With Oracle 12c’s introduction of Multitenant architecture, managing Data Guard setups became challenging when adding new databases to the primary CDB. In 12c Release 1, adding a pluggable database (PDB) would crash standby recovery. Release 2 improved this by offering the standbys=none option, letting you skip recovery for new PDBs. However, you then had to manually copy the new PDB to the standby and re-enable recovery. Otherwise, some PDBs ended up unprotected by Data Guard.

My colleague Sinan blogged about the pre-21c behavior here: https://database-heartbeat.com/2022/01/24/hot-clone-remote-pdb-in-data-guard/ 

With Oracle 21c (and in 26ai), creating or cloning a new PDB in the primary CDB now automatically copies it to the standby CDB and includes it in recovery: no interruptions or manual steps needed. Just ensure the standby CDB is open in read-only mode.

https://docs.oracle.com/en/database/oracle/oracle-database/26/sbydb/examples-of-using-oracle-data-guard.html#GUID-45590356-133B-47DC-AD19-3AA37348CD4D

This greatly simplifies working with the Multitenant architecture, which is now mandatory in 26ai.

Note: This feature works only for new or cloned PDBs, created locally or remotely. It does not support plugging in existing PDBs using a manifest file.

This post is part of a blog series.

Adding tempfiles in a Data Guard configuration has always been tricky. In 19c or lower, adding a tempfile doesn’t automatically create it on the standby database because tempfile operations (including creation) don’t generate redo. As a result, the standby doesn’t notice the change.

To work around this, you had to manually add the tempfile on the standby by opening the standby PDB in read-only mode—after stopping redo if you didn’t have an Active Data Guard license. Mohamadou explained this workaround in detail:
https://www.dbi-services.com/blog/dataguard-environment-and-database-tempfiles/

In release 26ai, the process is finally automatic—if you use Oracle-Managed Files (OMF) and set standby_file_management to auto. The system now writes a new redo marker whenever a tempfile is added, ensuring automatic creation on the standby.

My colleague Sinan also covered this topic here:
https://database-heartbeat.com/2023/09/26/temp-file-dg/

This post is part of a blog series.

Oracle AI Database Release Update 23.26.1 introduces tagging for broker configurations and their members. Tags (key-value pairs) let you add custom context to configuration objects like databases and far sync instances.

Currently, tags serve only for organization and classification, based on your business needs. For example, you might tag databases to track their lifecycle status, flag compliance requirements, or group them by location or department.

Use these commands to manage tags:

• EDIT CONFIGURATION SET TAG
• SHOW CONFIGURATION TAG
• EDIT DATABASE|FAR_SYNC|MEMBER SET TAG
• SHOW DATABASE|FAR_SYNC|MEMBER TAG

You can also view tags using the new fixed view V$DG_BROKER_TAG, or manage them with standard interfaces like the PL/SQL API and SQLcl.

Tag names beginning with “ORA” are reserved for possible future features, so avoid using that prefix. We may add new capabilities that rely on ORA-reserved tags.

Note: With 23.26.1, you have to explicitly activate this feature with:

This requirement will be removed in a future release update.

This post is part of a blog series.

Often, Data Guard setups use many standby databases, but only some should ever become primary. Others might serve as clone masters, reporting, testing, or staging only.
Previously, you couldn’t prevent an unwanted switchover or failover to these restricted standby databases. This was risky: customers must keep production workloads off test systems.
Oracle Database 26ai introduces a new broker property: PrimaryDatabaseCandidates. Set this to specify which databases can become primary. If you try to switch or fail over to a database not on the list, the broker blocks it.

You can update the candidate list at any time, so it’s flexible in emergencies.

Note: this only blocks broker-initiated switchovers and failovers. Manual SQL conversions bypass this check.

This enhancement has also been back-ported to 19.26.
My colleague Alex Blyth’s blogged about this property in the context of Exascale: https://alexblyth.net/2026/01/12/using-data-guard-broker-to-prevent-a-standby-database-becoming-the-primary/

This post is part of a blog series.

Oracle Data Guard 26ai adds JSON output support to DGMGRL.
Previously, you needed Linux tools like sed, awk, or grep to extract information from DGMGRL command-line output.
Now, you can display DGMGRL results as JSON, making them easy to parse with standard libraries or tools such as jq.
While you can programmatically interact with the broker using PL/SQL or REST, JSON output modernizes existing scripts and simplifies automation.

Enable JSON output by running DGMGRL in batch mode with the -json argument, or toggle it on and off in interactive mode with set json on and set json off.

This post is part of a blog series.

Before 26ai, updating properties or parameters across many members in a Data Guard configuration was a multi-step process. You had to run a separate command for each member, changing the DB unique name in each of them, and issuing the command for every one. Similarly, verification required running “show database” for each member.

Before 26ai:

Here’s the documentation for the new commands:

• EDIT ALL MEMBERS RESET (Parameter)
• EDIT ALL MEMBERS RESET (Property)
• EDIT ALL MEMBERS SET (Parameter)
• EDIT ALL MEMBERS SET (Property)
• SHOW ALL MEMBERS (Parameter)
• SHOW ALL MEMBERS (Property)

This post is part of a blog series.

Beyond SQLcl, DGMGRL, and the PL/SQL API, another key tool for managing Data Guard is Oracle REST Data Services (ORDS).

If your primary databases are set up with ORDS and accessible via REST (HTTPS), you can use REST calls to manage the Data Guard broker configuration. You can create configurations, add standby databases, modify properties, and more, all through standard REST requests.

Introduced in database version 21c and available with ORDS 21.4, this feature lets you easily automate Data Guard management within CI/CD pipelines or any tool that supports REST calls. ORDS also adds flexibility: by exposing only an HTTPS endpoint, you can manage Data Guard without opening SQL*Net ports, which may be preferable for security in some environments.

The REST API documentation for Data Guard is available here: https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/25.4/orrst/api-data-guard.html