Let me show you how you upgrade an entire container database, including all PDBs, to Oracle AI Database 26ai.
How to Upgrade
I’ve already prepared my database and installed a new Oracle home. The maintenance window has started, and users have left the database.
-
This is my AutoUpgrade config file:
global.global_log_dir=/home/oracle/autoupgrade/logs/CDB19 upg1.source_home=/u01/app/oracle/product/19 upg1.target_home=/u01/app/oracle/product/26 upg1.sid=CDB19sidcontains the name of SID or my database.- I specify the source and target Oracle homes. I’ve already installed the target Oracle home.
- Check the appendix for additional parameters.
-
I start AutoUpgrade in deploy mode:
java -jar autoupgrade.jar -config CDB19.cfg -mode deploy- AutoUpgrade starts by creating a guaranteed restore point to protect my database.
- Then, it analyzes the database for upgrade readiness and executes the pre-upgrade fixups. Next is the actual upgrade, followed by post-upgrade checks and fixups.
-
While the job progresses, I monitor it:
upg> lsj -a 30- The
-a 30option automatically refreshes the information every 30 seconds. - I can also use
status -job 100 -a 30to get detailed information about a specific job.
- The
-
In the end, AutoUpgrade completes the upgrade:
Job 100 completed ------------------- Final Summary -------------------- Number of databases [ 1 ] Jobs finished [1] Jobs failed [0] Jobs restored [0] Jobs pending [0] ---- Drop GRP at your convenience once you consider it is no longer needed ---- Drop GRP from CDB19: drop restore point AUTOUPGRADE_9212_CDB191927000 Please check the summary report at: /home/oracle/autoupgrade/logs/CDB19/cfgtoollogs/upgrade/auto/status/status.html /home/oracle/autoupgrade/logs/CDB19/cfgtoollogs/upgrade/auto/status/status.log- This includes the post-upgrade checks and fixups, incl. updating
/etc/orataband Grid Infrastructure configuration.
- This includes the post-upgrade checks and fixups, incl. updating
-
I review the Autoupgrade Summary Report. The path is printed to the console:
vi /home/oracle/autoupgrade/logs/CDB19/cfgtoollogs/upgrade/auto/status/status.log -
I take care of the post-upgrade tasks.
-
I update any profiles or scripts that use the database.
-
When I’m done testing the database – including application testing – and I decided that a rollback is not needed, I’ll drop the GRP:
SQL> drop restore point AUTOUPGRADE_9212_CDB191927000;
That’s It!
With AutoUpgrade, you can easily upgrade your entire CDB.
Check the other blog posts related to upgrade to Oracle AI Database 26ai.
Happy upgrading!
Appendix
What If My Database Is A RAC Database?
There are no changes to the procedure if you have an Oracle RAC database. AutoUpgrade detects this and sets CLUSTER_DATABASE=FALSE at the appropriate time. It also updates the Grid Infrastructure configuration.
For warp-speed upgrades, take a look at distributed upgrade.
What If I Use Oracle Restart?
No changes. AutoUpgrade detects this and automatically updates the Grid Infrastructure configuration.
What If My Database Is Encrypted
You must use an auto-login keystore. AutoUpgrade checks this during the pre-upgrade analysis.
Multitenant Upgrade
A few words about an upgrade of an entire CDB. AutoUpgrade first upgrades the root container. When that completes, it will upgrade the seed container and your PDBs. The latter part happens in parallel.
So, upgrading a CDB is always slower than just upgrading a single PDB. If you’re tight on time, consider upgrading just the PDB. This is called an unplug-plug upgrade.
Other Config File Parameters
The config file shown above is a basic one. Let me address some of the additional parameters you can use.
-
drop_grp_after_upgrade: AutoUpgrade doesn’t drop the GRP after the upgrade. This allows you to roll back even after a successful upgrade if your application testing reveals a problem. However, it means that you must manually remember to drop the GRP. Otherwise, you’ll eventually run out of space in FRA, and that will halt your database. Set this parameter to yes, and AutoUpgrade drops the GRP if the upgrade completes without problems. -
timezone_upg: AutoUpgrade upgrades the database time zone file after the actual upgrade. This requires an additional restart of the database and might take significant time if you have lots ofTIMESTAMP WITH TIME ZONEdata. If so, you can postpone the time zone file upgrade or perform it in a more time-efficient manner. -
raise_compatible: If you want to raise the initialization parameterCOMPATIBLEimmediately after the upgrade, you can use this parameter. Don’t use if you have standby databases, because there’s a specific procedure for raisingCOMPATIBLEin a Data Guard configuration. Don’t use it if you want to keep the option of downgrading. -
before_action/after_action: Extend AutoUpgrade with your own functionality by using scripts before or after the job. -
em_target_name: Allow AutoUpgrade to create blackouts before restarting the database and to update the target configuration after the upgrade. Requires a local installation of emcli. See this blog post for details. -
rman_catalog_connect_string: Relevant for databases that store backup metadata in a recovery catalog. Upgrades the recovery catalog schema following an upgrade. See this blog post for details.


