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

This post is part of a blog series.

The PL/SQL APIs published for general use in 26ai have also powered SQLcl’s command line for some time. SQLcl has supported Data Guard commands since version 21c. It’s another nice addition that you get when upgrading from 19c.

SQLcl is a robust Java-based command line tool that excels at running SQL and can also (incomplete list):

• launch Data Pump jobs
• retrieve metadata
• run Liquibase commands
• manage projects
• operate as an MCP server for natural language queries
• and now, execute Data Guard commands

To run a Data Guard command, simply prefix a standard DGMGRL command with “DG ” in your SQLcl session.

While not every Data Guard feature is available—some validation commands are missing—core management commands work without issue. The real advantage is convenience: you can use both SQL and Data Guard commands from the same interface, no need to switch tools.

Looking ahead, we plan to add more features, and SQLcl will eventually become our recommended tool for Data Guard. Today, you can switch between SQLcl and DGMGRL as needed. Note: Observer functionality remains unique to DGMGRL; SQLcl does not yet support it.

This post is part of a blog series.

Most people don’t know that, until recently, Data Guard broker relied on internal C routines to execute operations inside the database.

Now, more and more of these routines have moved into “fixed packages”: PL/SQL packages embedded directly in the Oracle binary. These packages are accessible even when databases are mounted (but not necessarily open).

The broker now uses these fixed packages, and so do other components outside the “dgmgrl” tool. With Oracle 26ai, we are exposing these internal PL/SQL functions through the wrapper package DBMS_DG.
Starting with Oracle 26ai, you can use over 30 PL/SQL functions (all documented in the Data Guard Broker Administration Guide) to programmatically configure and manage Data Guard broker configurations.

This change makes automation more robust: instead of shell commands like AWK or grep, you can rely on programmatic PL/SQL APIs. This should simplify integration with automation tools and CI/CD pipelines.

This post is part of a blog series.

I’ve previously blogged about how in 26ai you can automatically prepare the primary database using DGMGRL’s command “PREPARE DATABASE FOR DATA GUARD“; you can find the link here for more details.

Many Oracle ACEs and bloggers also blogged about it:

• https://oracle-base.com/articles/21c/data-guard-prepare-database-for-data-guard-21c
• https://www.dbi-services.com/blog/oracle-20c-the-new-prepare-database-for-data-guard/
• https://gavinsoorma.com.au/knowledge-base/prepare-database-for-data-guard/

As of version 23.26.0 (released October ’25), the “PREPARE DATABASE FOR DATA GUARD” command supports both primary and standby databases. While you’ll still need to create your standby database manually, the command now recognizes the role of the database and automatically sets recommended parameters, creates required components, and enforces the necessary settings for joining a Data Guard configuration.

This post is part of a blog series.

With a Data Guard asynchronous configuration, there is usually one asynchronous process that handles redo for multiple standby databases. If one or more standby databases are much slower at receiving redo than the others, Data Guard can automatically create extra asynchronous processes for the slower ones.

Before version 26ai, each asynchronous process could open only one connection for each standby database. This limited throughput when network setups restricted bandwidth per connection.

Starting in 26ai, an asynchronous process can notice when a connection is using all its available bandwidth and then open extra connections for better throughput and less lag. This change helps especially in cloud environments, where each connection often has its own bandwidth limit. On the receiving side, there is one RFS process for every connection.

You do not need to change any configuration to get this benefit. Just upgrade to 26ai and the improvement automatically works.