This post is part of a blog series.
One of my favorite Oracle Active Data Guard features is Rolling Upgrades. Introduced in 12c, Rolling Upgrades use the DBMS_ROLLING package to keep downtime during upgrades to a minimum: your apps stay connected almost the entire time.
Here’s how it works in real life: when it’s time for a major upgrade or maintenance, you convert your physical standby database to a transient logical standby (so it uses SQL apply instead of redo apply).
With that done, your standby is open for read/write. You stop replication, upgrade the standby (say, to 26ai), and then bring it back into sync with the primary.
Once everything’s caught up, you finish with a switchover: the upgraded standby becomes the new primary. Apps stay connected most of the time; actual downtime is basically just the switchover itself. DBMS_ROLLING automates everything except the actual upgrade, which you can handle with AutoUpgrade or Fleet Patching and Provisioning.
If your applications use a proper connection pool, they’ll disconnect and transparently reconnect during the switchover, so your users won’t even notice. But sticky sessions (apps that hold onto DB connections) used to be a problem: connections would break, and apps had to catch exceptions and reconnect, or had to be restarted manually.
Now, with 26ai, everything’s easier. DBMS_ROLLING’s switchover supports Application Continuity and Transparent Application Continuity!
Even sticky-session apps automatically reconnect and pick up where they left off, so transactions flow smoothly. That means that application can start a transaction in 19c and finish it in 26ai! 🤯 This is possible because Oracle has backported this feature to 19c (19.30 release update), letting you upgrade from 19c to 26ai with Application Continuity support.
Latest posts by Ludovico (see all)
- Data Guard 26ai – #7: Rolling Upgrade with Application Continuity - February 4, 2026
- Data Guard 26ai – #6: Up to four Fast-Start Failover Observers - February 3, 2026
- Data Guard 26ai – #5: Fast-Start Failover Observer Priority - February 2, 2026