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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
$ dgmgrl sys/{password} DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Jan 12 15:05:07 2026 Version 19.29.0.0.0 Copyright (c) 1982, 2025, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected to "dgb1929ru" Connected as SYSDBA. DGMGRL> set time on 15:05:18 DGMGRL> switchover to dgb1929rub Performing switchover NOW, please wait... Operation requires a connection to database "dgb1929rub" Connecting ... Connected to "dgb1929rub" Connected as SYSDBA. New primary database "dgb1929rub" is opening... Operation requires start up of instance "b1929ru" on database "dgb1929ru" Starting instance "b1929ru"... Connected to an idle instance. ORACLE instance started. Connected to "dgb1929ru" Database mounted. Switchover succeeded, new primary is "dgb1929rub" 15:06:02 DGMGRL> |
Total: ~44 seconds
Switchover in 23.26.1
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
$ dgmgrl sys/$pass DGMGRL for Linux: Release 23.26.1.0.0 - Production on Mon Jan 12 15:43:29 2026 Version 23.26.1.0.0 Copyright (c) 1982, 2026, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected to "dgdb261" Connected as SYSDBA. DGMGRL> set time on 15:43:54 DGMGRL> switchover to dgdb261b 2026-01-12T15:43:55.742+00:00 Performing switchover NOW, please wait... 2026-01-12T15:43:55.811+00:00 Operation requires a connection to database "dgdb261b" Connecting ... Connected to "dgdb261b" Connected as SYSDBA. 2026-01-12T15:43:55.971+00:00 Continuing with the switchover... 2026-01-12T15:43:58.726+00:00 New primary database "dgdb261b" is opening... 2026-01-12T15:43:58.728+00:00 Operation requires start up of instance "db261" on database "dgdb261" Starting instance "db261"... Connected to an idle instance. ORACLE instance started. Connected to "dgdb261" Database mounted. 2026-01-12T15:44:14.181+00:00 Switchover succeeded, new primary is "dgdb261b" 2026-01-12T15:44:14.193+00:00 Switchover processing complete, broker ready. |
Total: < 20 seconds
😎
The following two tabs change content below.
Latest posts by Ludovico (see all)
- Data Guard 26ai – #24: Validate DGConnectIdentifier - March 13, 2026
- Data Guard 26ai – #23: New view V$DG_BROKER_PROPERTY - March 9, 2026
- Data Guard 26ai – #22: History of role transitions - March 2, 2026
Could you please explan the reason why it is faster / what meachanism has changed
Hi Chandan, as I mention in the referenced link:
The faster transitions are the result of several bug fixes and code improvements that happened over the first few release updates of Oracle Database and Oracle Grid Infrastructure 23ai.
* Parallelization of independent tasks.
* Removal of unnecessary sleep routines or repeated checks.
* Optimizations at the Database level (RAC, Multitenant, Recovery).
* Optimizations at the Clusterware level.
Some optimizations have been backported to Oracle Database 19.27 and are visible when used in conjunction with Oracle Grid Infrastructure 23ai.
Interesting. Note however that the key indicator is the time to open the new primary. The time afterwards (stopping and opening the former primary) is irrelevant for the business/application. From the moment the new primary is open, your application can continue.
Also, it is great that Oracle improves this feature but if you do a switchover in a Db System in OCI via the web GUI, you loose 10’s of seconds (minutes?) before the switchover is actually started (due to the slow dcs framework in the background).
Good observations, Geert.
The actual real indicator is how much time it takes for an application between draining (or getting disconnected) and reconnecting. This is what the business should care about.
As you say, the application can often reconnect to the new primary before the new standby starts recovering again.
Regarding OCI, it’s again the same. If I click on “Switchover”, it might take let’s say additional 30 seconds to start the actual switchover (I don’t know the actual numbers), and it might take a couple of minutes at the end to show the “green light” in the console, but the actual downtime perceived by the application will be the same.
If you need to stop the application before the switchover, that’s another story. In that case, either you work on making the client configuration resilient to a switchover, or you can trigger the switchover out of band (not using the cloud control plane).