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.

This post is part of a blog series.

Just like observer priorities, this is another cool feature first introduced in Oracle 21c.

If your Fast-Start Failover setup doesn’t have a third site for the observer, the usual advice is to place it with your primary database. But if you want true high availability, making sure the observer is always up, you’ll want two observers on the primary site and two on the secondary site (for when the standby takes over as primary).

Before 21c, you could only use up to three observers, which made this setup impossible.

Starting with 21c (and, of course, 26ai), you can now configure four observers. That solves the high-availability challenge when you’ve only got two sites.

This post is part of a blog series.

Technically, this is a 21c feature, but it’s worth calling out some of those 21c improvements, because most customers are still running on 19c or earlier. That means when you upgrade to 26ai, you’ll pick up all the 21c goodies too!

Here’s one: Fast-Start Failover observer’s priority. In 19c, you could list preferred observers for each possible primary with the property PreferredObserverHosts , but you couldn’t actually assign an observer priority based, for example, to the observer’s location.

21c fixes that. Now, you can give each observer a priority by adding a colon and a number right after the hostname. The lower the number, the higher the priority. This lets you spell out exactly which observers should be chosen first if a promotion is needed.

The diagram below shows an example: the external site’s observer is set as the top pick for both databases at the primary and the secondary sites, with each site’s local observer as the backup (which is our recommendation in this case).

You can create that setup now—thanks to observer priorities.

This post is part of a blog series.

Before Oracle 26ai, Active Data Guard’s DML redirection was significantly slower than DMLs executed directly on the primary database. When your app ran DML on the standby, the changes had to be executed on the primary and then returned and applied on the standby before your session could continue. That led to unnecessary pauses, with sessions often waiting on the “standby query scn advance” wait event.

Most of that waiting isn’t always needed. Theoretically, you only have to wait if your session needs to commit or read the updated data.

Oracle AI Database 26ai fixes this. Now, once DML succeeds on the primary, your session can continue with the next statement (or commit) without waiting. The only wait required to keep ACID consistency is upon commit or read. With this brilliant change, redirected transactions are up to 33 times faster in our internal tests compared to 19c.

This new behavior is on by default, but if you prefer the old way, you can set the hidden parameter “_alter_adg_redirect_behavior” to “sync_each_dml”.

The chart below shows the difference. We tested both 19c and 26ai (primary and standby) with SwingBench running 16 concurrent order-entry sessions, each doing a mix of “newCustomerProess” and “browseProducts” operations.

This post is part of a blog series.

In Data Guard, when Fast-Start Failover runs in Maximum Performance mode, the FSFP process tracks lag to keep the primary database within safe limits.
Traditionally, FSFP used APPLY LAG to measure lag, a legacy from older redo transport. But APPLY LAG may not reflect real data loss risk: TRANSPORT LAG shows how much data hasn’t reached the standby.
With 26ai, you can set FastStartFailoverLagType to APPLY (default) or TRANSPORT.
Consider switching this property to TRANSPORT to track real data loss exposure.

This post is part of a blog series.

Did you know that Oracle Data Guard fast-start failover in maximum performance mode can briefly stall your primary database?

Most users don’t notice, but in environments with strict performance needs, these stalls can matter.

Here’s why: when the database shifts from “UNDER LAG” to “OVER LAG” status, the primary waits for the observer’s acknowledgment. This pause ensures the database doesn’t breach its recovery point objective set with the FastStartFailoverLagLimit property, but it can last up to three seconds (default observer ping time).

Stalls are especially common if the standby can’t keep up with primary redo generation, causing frequent state transitions.

Now in 26ai, the new FastStartFailoverLagGraceTime property lets the observer acknowledge a “pre-stall” before reaching the real lag limit. That way, when the database hits the actual limit, it won’t need to pause: the acknowledge’s already done.
This simple change removes stalls during state transitions, so even the strictest environments meet their performance goals.

What you need to do: set FastStartFailoverLagGraceTime to a value greater than 0 and lower or equal to 3 to make this feature effective. The default of 0 keeps the old behavior.