Discover refreshable clone PDB with Autoupgrade

AutoUpgrade with a refreshable clone is basically “zero‑panic upgrades with a live copy of your database.”.

What problem it solves

Traditionally you had to schedule a maintenance window, stop everything, take a backup, upgrade, and hope nothing went wrong.

With a refreshable clone PDB, AutoUpgrade builds and continuously syncs a copy of your database while production stays online. At cutover time, you just stop users, do a last refresh, convert/upgrade the clone, and switch them over. If something goes wrong, the original source is untouched and you can fall back quickly.

Core idea in simple terms

Think of your non‑CDB or old‑version PDB as the “master” and the refreshable clone PDB as a “follow‑me” copy sitting in the target CDB.

AutoUpgrade:

• Creates a PDB in the target CDB via database link (initial clone of datafiles).
• Marks it as refreshable, so redo from the source is applied and it keeps rolling forward.
• Lets you test the clone (read‑only) while users are still working on the source.
• At a controlled start time, runs a last refresh, disconnects it from the source, converts it to a normal PDB, and upgrades it.

From your point of view: you prepare everything days in advance, and the real downtime shrinks to “final refresh + upgrade + app switch.”

High‑level lifecycle

For a non‑CDB to PDB migration or a PDB upgrade, the flow looks like this:

Preparation

• You have a source: non‑CDB 12.2/19c or older PDB.
• You have a target: a higher‑version CDB (for example 23ai/26ai) with enough space and network.

Initial deploy with AutoUpgrade

• You configure AutoUpgrade with the source and target, plus the parameter telling it to use refreshable clone PDB.
• In deploy mode, AutoUpgrade creates the pluggable database in the target CDB via DB link, copies the datafiles, and defines it as refreshable.
• From now on, redo is shipped from source to target and applied, so the clone stays close to current.

Sync phase (low‑risk testing)

• The source database stays fully online; business keeps running.
• The refreshable clone is read‑only, so you can query it, run app smoke tests, check performance characteristics, etc.
• AutoUpgrade keeps the job running in the background, doing periodic refreshes.

Cutover (final refresh and conversion)

• When you reach the maintenance window, users leave the system and you quiesce activity on the source.
• AutoUpgrade performs a final refresh: last redo from source is applied on the clone so you don’t lose any committed data.
• The clone is then disconnected from the source, turned into a regular PDB, and AutoUpgrade moves into the upgrade and conversion steps (non‑CDB to PDB conversion if needed, then catalog/PSU/UTLRP, etc.).

Post‑upgrade and fallback

• You point applications to the new PDB in the target CDB.
• The original source database still exists; if you hit a show‑stopper, you can redirect apps back to it and plan a new attempt.

In practice, the “scary” part is only the final refresh and the moment you switch your apps.

Why DBAs like this pattern

Some clear advantages:

• Minimal downtime: Most of the heavy lifting (copy + sync) happens while production is running; downtime is limited to final refresh and upgrade.
• Built‑in rollback: Because the source stays untouched, you always have a clean fallback without restore/recovery.
• Realistic testing: You test against a clone built from real production data that is almost up‑to‑date, not a weeks‑old backup.
• Automation: AutoUpgrade orchestrates the create‑clone, refresh, disconnect, convert, and upgrade steps; you mostly steer with parameters and commands instead of custom scripts.

Trade‑offs are mainly around resources: you need disk, CPU, and network to maintain the refreshable clone, and you have to ensure redo shipping is reliable (archivelog gaps or network glitches can break the refresh and need fixing).

Typical example

Imagine you need to move a 19c non‑CDB to a new 26ai CDB on a different host, with less than 30 minutes downtime:

• Monday: you configure AutoUpgrade with the refreshable clone option, start the job. The tool creates the PDB clone in the 26ai CDB and starts streaming redo. Users never notice.
• Next days: you let it refresh every few minutes, developers connect read‑only to the clone and test their application against 26ai. Everything looks good.
• Saturday night: you enter the maintenance window, let open transactions finish, stop app traffic, and tell AutoUpgrade to proceed to the final refresh. Once that’s done, it disconnects the clone, upgrades it, and runs post‑upgrade steps.
• After checks, you change the service names on the app side so they point to the new PDB. Your downtime is mostly spent waiting for the upgrade scripts, not copying terabytes of data.