Something every technical or non-technical user working with a database today is aware of – Keeping databases current is essential for security, performance, and access to the latest innovations. Upgrading a database while essentially, have traditionally required a trade-off: planned downtime and operational coordination.

With Autonomous AI Database Serverless, that experience has been steadily evolving. With this latest enhancement announcement, scheduled upgrades can now be performed fully online for read-only workloads, significantly reducing disruption. As before, it continues to be a simple one-click upgrade!

In this post I want to introduce you to this enhanced online upgrade capability as well as help architect the options for your fleet of databases’ planned upgrade, with minimal-to-no downtime.

What’s New: Read-Only Online Upgrades

Previously, upgrades followed a familiar model: A user schedules an upgrade and plans their workloads around a short window of downtime during which the database is totally inaccessible. While ADB-S was already well ahead of the curve, upgrading your database and all its connected databases resources in less than 15 minutes, Oracle has taken a new leap forward in upgrading your database with no downtime – Your database stays online for read-only workloads throughout the upgrade.

What’s better is there is nothing new for a user to do here – Following the same scheduled upgrade option as before, the database remains available for queries during the upgrade window — eliminating blackout downtime!

         Continuous Query Access
                  │
                  ▼
   ┌───────────────────────────────┐
   │   Primary Database (Source)   │
   │   Read/Write → Read-Only Mode │
   └──────────────┬────────────────┘
                  │
                  │  Sync / Prepare Upgrade
                  ▼
   ┌───────────────────────────────┐
   │   Upgraded Copy in background │
   │                               │
   └──────────────┬────────────────┘
                  │
                  │  Cutover
                  ▼
   ┌───────────────────────────────┐
   │   New Primary Database        │
   │   (Read/Write Restored)       │
   └───────────────────────────────┘

Now, during a scheduled upgrade,

  • The database transitions temporarily to read-only mode, read-only queries continue uninterrupted
    • Application can run queries, dashboards and reports remain live
  • Only DML is restricted during the upgrade window
  • After cutover, applications reconnect, full read-write functionality resumes!

As is always recommended for a production-ready database, use connection pooling and Application Continuity to have your sessions seamlessly reconnect and replay where they left off.

This removes one of the biggest operational pain points: downtime for query workloads.

Going Further: Avoiding downtime with OCI GoldenGate (Read-Write Online)

For your systems that cannot tolerate any interruption — including write restrictions — a slightly more involved replication-based approach using OCI GoldenGate enables fully online upgrades.

Instead of upgrading in place, this approach creates a parallel synchronized upgraded database to which you will cutover.

        Continuous Replication (CDC)

   ┌───────────────────────┐        ┌───────────────────────┐
   │   Source ADB          │        │   Upgraded Target ADB │
   │   (19c)               │        │   (26ai)              │
   │   Read / Write        │        │   Read / Write        │
   └─────────┬─────────────┘        └─────────┬─────────────┘
             │                                │
             │                                │
             ▼                                ▼
      ┌───────────────┐              ┌───────────────┐
      │   Extract     │     sync     │   Replicat    │
      │ (GoldenGate)  │    ──────▶   │ (GoldenGate)  │
      └───────────────┘              └───────────────┘

                ──────── Cutover ────────▶

   Applications switch connection to Target at planned time (no downtime)

At a high-level, upgrading Autonomous AI Database using GoldenGate consists of the following simple steps:

  • From a 19c source database, you may full clone a 26ai target database
  • Configure GoldenGate’s extract/replicat to synchronize the target database with the source production database using continuous change data capture (CDC)
  • Test your environment in active/live mode.
  • Cut over the application to the target database.
  • If necessary, you may now also upgrade the source production database being replicated to and switch back.

Key characteristics

  • No downtime for reads or writes
  • No service interruption
  • Safe fallback (source remains intact)

Final Thoughts – Choose the right approach, but you can’t really go wrong

The upgrade experience in Autonomous Database Serverless is moving toward a clear goal: eliminating disruption as a constraint. While the default one-click upgrade option is now more seamless than ever and will suit many user’s needs, to summarize the options mentioned above:

  • Query availability sufficient during upgrade → Choose Read-only online upgrade (new default behavior)
  • Read-Write required upgrades → Choose GoldenGate replication based upgrade

For most analytical workloads, upgrades now happen without users even noticing. For more detail on scheduled upgrades refer to the official documentation here.

Go login to your Oracle Cloud console and schedule an upgrade to 26ai today!