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.
Latest posts by Ludovico (see all)
- Data Guard 26ai – #4: Faster DML Redirection - January 30, 2026
- Data Guard 26ai – #3: Choice of Lag Type for Fast-Start Failover - January 29, 2026
- Data Guard 26ai – #2: Minimized Stall in Maximum Performance - January 28, 2026