Data Guard 26ai – #4: Faster DML Redirection

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.

a chart shows that 26ai redirected DML transactions are 13x faster in mixed workloads with 5% of writes, and 33x faster in mixed workloads with 25% writes.

Data Guard 26ai – #3: Choice of Lag Type for Fast-Start Failover

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.

a table shows that before 26ai "APPLY" is the only lag type, while in 26ai it can also be TRANSPORT.

Data Guard 26ai – #2: Minimized Stall in Maximum Performance

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).

when transitioning to "OVER LAG" the primary stalls waiting for the observer's acknowlegment.Stalls are especially common if the standby can’t keep up with primary redo generation, causing frequent state transitions.

There's a grace period where the primary asks the observer to pre-acknowledge the state change before stalling.
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.

 

Data Guard 26ai – #1: Faster role transitions

This post is part of a blog series.
I’ve already blogged about it on the official Oracle MAA Blog (read here) , but let me insist on this.

Role transitions (switchover, failover) are much faster in Oracle Data Guard 26ai.

Depending on the configuration and workload, they can be up to five times faster! No changes to the application code or configuration: you get this improvement out of the box.

Here’s an example of two identical configurations using 19.29 and 23.26.1, one PDB, and no application services (basically, an empty database):

Switchover in 19.29

Total: ~44 seconds

Switchover in 23.26.1

Total: < 20 seconds

😎

Mini-blog series: Oracle Data Guard 26ai new features

Thank you for your patience: Oracle AI Database 26ai is now available on Linux x86_64 systems!
This release delivers many new features, including key updates to Data Guard and Active Data Guard: two areas I track as a product manager.
Some improvements aren’t listed in the feature guide, so I’m launching a daily series of brief blog posts over the next month. Each one will spotlight a practical change or enhancement you can try right away.