Oracle 21c is an innovation release, so it may not be suitable for most production systems. Please read this before using Oracle 21c for anything real. - Long Term Releases, Innovation Releases and Preview Releases? Even if you are not planning to upgrade to 21c, it is still worth practicing the upgrade processes, as these will be the same for Oracle 23ai, the next long term release. Upgrades can be very complicated, so you must always read the upgrade manual , and test thoroughly before considering an upgrade of a production environment.

There is a limited set of versions supported for direct upgrade to Oracle 21c. You will notice these are all from the 12.2 branch of code, since 18c was 12.2.0.2 and 19c was 12.2.0.3. All the 21c upgrade articles on this site assume you are starting from a supported version for direct upgrades. If you are not currently on a version supported for direct upgrades, you must do additional upgrades to get to a supported version before doing the final upgrade to Oracle 21c. Some example paths are shown below, but there are many permutations depending on patch versions. All intermediate upgrades should be performed following the instructions relevant for that version. If you are already lagging behind on upgrades, it's worth progressing your existing databases to the current long term release (19c), just so it makes upgrades to the next long term release (23ai) easier.

1
2
3
4

19c, 18c, 12.2

11.2.0.4 -> 19c -> 21c
10.2 -> 12.1 -> 19c -> 21c

The non-CDB architecture is dessuported in Oracle 21c, so we can't run a non-CDB instance of 21c. This also means we can't pass through a non-CDB version of 21c on our way to converting an instance to 21c multitenant. This has a profound impact on our approach to upgrading to Oracle 21c, as you will see later. Every upgrade scenario ends with a CDB and PDBs. The desupport of the non-CDB architecture may mean some of the upgrade scenarios you are used to are no longer possible. It's worth practicing the new variations before you have to do something for real.

For previous upgrades you have probably used the "preupgrade.jar" tool to check compatibility issues before performing upgrades. The "preupgrade.jar" tool creates automatic fixup scripts for many issues, and warns where manual intervention is needed prior to upgrade. From Oracle 21c onward this tool has been replaced with the "autoupgrade.jar" tool. This tool can be used in the same way as the "preupgrade.jar" tool, but it can do a lot more. In addition to handling the pre/post fixup scripts, it can manage the instance state and copy config files between homes, so a single deploy phase can perform all the work needed to take you from your start point to the end point. It's worth investing some time playing with this utility to get a feel for what it is capable of. The articles on this site are all relatively simple, dealing with single instance upgrades on a single server, but the AutoUpgrade tool can also be used for Data Guard and Real Application Cluster (RAC) upgrades, as well as migrations to new servers. Check out the documentation for details. Always download the latest "autoupgrade.jar" file from MOS 2485457.1 .

1
2
3

cd $ORACLE_BASE/product/21.0.0/dbhome_1/rdbms/admin
mv autoupgrade.jar autoupgrade.jar.`date +"%Y"-"%m"-"%d"`
cp /tmp/autoupgrade.jar .

There are several tools that can be used to upgrade the database. - AutoUpgrade : This should be your main tool. See above. - Database Upgrade Assistant (DBUA) : A GUI tool to upgrade the database. I've not used a GUI tool for upgrades for a very long time, so I ignore this tool. Each to their own. - Export/Import : This is a simple solution for small databases. It also has the advantage of being version and platform independent, so it is useful when migrating between operating systems. It will be very slow for large databases. - Transportable Database : A variation of transportable tablespace, where the whole database is transported. Each of these have their pros and cons, but I would expect the AutoUpgrade tool the be the best option for the majority of cases.

There are many possible upgrade scenarios, but here are a few with examples in the linked articles. Scenario 1 : We have a multitenant database with one or more PDBs on a database version that supports direct upgrade to 21c. We decide to upgrade the CDB along with all the PDBs in a single step. Scenario 2 : We have a multitenant database with one or more PDBs on a database version that supports direct upgrade to 21c. We decide to upgrade one or more PDBs by unplugging them from the old container, and plugging them into a new Oracle 21c container to upgrade them. Scenario 3 : We have a non-CDB database on a version that supports direct upgrade to 21c. We convert the non-CDB database to a pluggable database (PDB) in an Oracle 21c CDB. Opening the new PDB in Oracle 21c automatically triggers an upgrade and conversion from a non-CDB database to a PDB. We use the AutoUpgrade tool to handle the upgrade. Scenario 4 : We have a non-CDB database on a version that supports direct upgrade to 21c. We convert the non-CDB database to a pluggable database (PDB) in an Oracle 21c CDB. Opening the new PDB in Oracle 21c automatically triggers an upgrade and conversion from a non-CDB database to a PDB. We use the manual unplug/plugin approach to handle the upgrade.

By default Oracle 21c uses read-only Oracle homes. This functionality was introduced in Oracle 18c, and you can read about it here. For more information see: Hope this helps. Regards Tim...