AutoUpgrade now supports unplug-plug upgrades. You unplug a PDB from a lower release CDB and you plug it into a higher release CDB. After plug-in the PDB is upgraded and eventually it can be opened in normal, READ WRITE mode.
When it comes to upgrading in the multitenant world, I am a big fan of unplug-plug upgrades. The concept comes with a number of benefits:
- It is much faster to upgrade an individual PDB using unplug-plug compared to a CDB with just one PDB in it. When you do an unplug-plug upgrade, the database just need to upgrade the PDB. Compare that to a CDB which first upgrades CDB$ROOT, and then PDB$SEED and any user PDBs.
- You don’t have to arrange downtime for all the PDBs in the CDB. Downtime is just needed for the PDB that you will upgrade.
- Combine it with refreshable PDBs and you can still have a really good fallback option. You can check out a previous blog post to see how you can use refreshable PDBs.
AutoUpgrade and Unplug-plug Upgrade
Starting from version 21, AutoUpgrade can now perform unplug-plug upgrades. A newer version of AutoUpgrade can upgrade to older database releases as well, so don’t worry if the AutoUpgrade version doesn’t match the Oracle Database release that you are upgrading to.
There are some requirements that must be met in order to perform unplug-upgrade, so I suggest that you take a look in the documentation.
You have to create the target CDB yourself. It is by design that AutoUpgrade doesn’t do this for you. First, creating a CDB requires a lot of information and it can be done in many different ways (ASM? Which components? RAC?). You would need a very long config file to supply all that information. Also, it takes time to create a CDB and if AutoUpgrade would have to do that inside the maintenance window, it would be prolonged considerably.
During unplug-plug upgrades AutoUpgrade also allows you to change the name of the PDBs and you can decide whether you want to reuse the unplugged data files or take a copy.
Imagine the following AutoUpgrade config file:
upg1.sid=CDB1 upg1.target_cdb=CDB2 upg1.pdbs=hr,logistics upg1.source_home=/u01/app/oracle/product/126.96.36.199 upg1.target_home=/u01/app/oracle/product/19 upg1.target_pdb_name.hr=people
AutoUpgrade will unplug PDBs hr and logistics from CDB1 and plug them into CDB2. In addition, it will change the name of hr to people when it is plugged into CDB2. Finally, you must specify the Oracle Home of the two CDBs, so AutoUpgrade can set the environment correctly and connect to the databases.
If you use
lsj command to monitor the progress it does actually look like you are only upgrading one of the PDBs:
upg> lsj +----+-------+---------+---------+-------+--------------+--------+------------------+ |Job#|DB_NAME| STAGE|OPERATION| STATUS| START_TIME| UPDATED| MESSAGE| +----+-------+---------+---------+-------+--------------+--------+------------------+ | 100| CDB1|DBUPGRADE|EXECUTING|RUNNING|20/12/22 15:25|15:29:03|13%Upgraded PEOPLE| +----+-------+---------+---------+-------+--------------+--------+------------------+ Total jobs 1
But if you look into the details with
status -job 100 you can see that both PDBs are upgraded in parallel:
upg> status -job 100 ... (removed a lot of information) Details: [Upgrading] is [0%] completed for [cdb1-people] +---------+-------------+ |CONTAINER| PERCENTAGE| +---------+-------------+ | PEOPLE|UPGRADE [13%]| |LOGISTICS|UPGRADE [13%]| +---------+-------------+
When the upgrade completes, the PDBs are ready to be used. I suggest that you verify that the databases are open in READ WRITE mode and not in restricted mode. Finally, save the state, so the PDBs start automatically together with the CDB:
SQL> select name, open_mode, restricted from v$pdbs where name in ('PEOPLE', 'LOGISTICS'); SQL> --Verify open_mode=read write and restricted=no SQL> alter pluggable database people save state; SQL> alter pluggable database logistics save state;
With unplug-plug upgrades you can’t use Flashback Database as your fallback plan. It doesn’t work across the plug-in operation. You either have to:
- Instruct AutoUpgrade to copy the unplugged data files before it plugs into the higher release CDB. That way, you still have the old unplugged data files, and just re-create the PDB in the lower release CDB. But you will have extra downtime because you need to copy the data files.
- Use Refreshable PDBs to build a copy of your PDB in the higher release, target CDB. When you want to do the upgrade, perform the last refresh and upgrade the refreshable PDB.
Both of the above options require additional disk space to hold a copy of the database.
Of course, you can also use your regular backups as fallback.
Your Target CDB Has a Standby Database?
For now, don’t use AutoUpgrade to make unplug-plug upgrades, if the target CDB has standby databases. A plug-in operation with a standby database is a tricky maneuvre, at least when you want to re-use the data files. We are still trying to figure out how to implement it in AutoUpgrade.
Having said that, it is absolutely doable. You can read more about in the following MOS notes:
- Reusing the Source Standby Database Files When Plugging a PDB into the Primary Database of a Data Guard Configuration (Doc ID 2273829.1)
- Making Use Deferred PDB Recovery and the STANDBYS=NONE Feature with Oracle Multitenant (Doc ID 1916648.1)
You Are Using TDE Tablespace Encryption?
For now, don’t use AutoUpgrade to perform unplug-plug upgrades, if any tablespace in the PDB is encrypted with TDE Tablespace Encryption. We are working on making AutoUpgrade capable of better interacting with the TDE keystore, so keep an eye out for coming versions.
If TDE Tablespace Encryption is enabled in the target CDB, you can still use AutoUpgrade. The PDB will be plugged in as an unencrypted PDB.
Doing unplug-plug upgrades is now supported by AutoUpgrade as of version 21. It includes useful features for renaming PDBs and using copies of unplugged data files.
There is a video on YouTube that shows the procedure. And while you are there, I suggest that you subscribe to our channel.
- Understanding Unplug-Plug Upgrades with AutoUpgrade – Oracle Database 21c Upgrade Guide
- About Refreshable Clone PDBs – Oracle Database 19c Administrator’s Guide
- Upgrading in the cloud – VM DB Systems – 188.8.131.52 PDB to 19c – blog post
- New Version of AutoUpgrade – blog post
- AutoUpgrade Tool (Doc ID 2485457.1) – My Oracle Support
7 thoughts on “How to Upgrade a Single PDB”
Does the comment of not using autoupgrade for PDB (with TDE enabled) upgrade still holds true?
Yes and no. We have made some enhancements to non-CDB to PDB conversion of an encrypted database. Please see this blog post: https://dohdatabase.com/2021/08/24/how-to-upgrade-an-encrypted-oracle-database-and-convert-to-pdb/.
We are still working on having full support for TDE databases. We are getting close to have something that we can ship. I expect it will be released in one of the next versions of AutoUpgrade.
Thanks Daniel..yes it helps to address one of my requirement where I need to upgrade non-cdb … Looking forward when solution for PDB upgrade (TDE enabled) is available using Autoupgrade..
If you are interested, I might be able to get you a beta version that you can test with.
Thanks for the update. That would be great help… Please advise if I need to do something for it
Please send me an email – email@example.com. Kindly include the amount of databases and versions of Oracle Database you are upgrading from and to.
Thanks Daniel. Just sent the email with details.