It is really easy to upgrade a database to 19c using the console:

In addition, the documentation is quite good and elaborate. I won’t make a copy/paste of the documentation, and also because things really move fast in the cloud, you should visit the documentation for up-to-date information.

Before Upgrade

First, your VM must be running Oracle Linux 7 and Grid Infrastructure must be version 19. If your system doesn’t meet these requirements either:

• Move the database to a new DB System that meets these requirements via cloning or backup/restore, or
• Use manual upgrade which is described in other post in the series.

To check the OS version:

[oracle@host]$ cat /etc/os-release

To check GI version:

[grid@host]$ crsctl query crs activeversion

Precheck

Start by running a precheck. I recommend to always upgrade to 19.0.0.0 as it will automatically give you an Oracle Home including the latest release update.

The console will notify you if something critical comes up during the precheck.

If you want to see the output from the precheck you must log on to the database host and find the file:

vi $ORACLE_BASE/cfgtoollogs/dbua/upgrade<timestamp>/$ORACLE_UNQNAME/upgrade.xml

Only the XML output is available, which might be a little hard to read. If you prefer you can also download AutoUpgrade to the server, and run it in analyze mode. It can produce a much better output, and it works even if the target Oracle Home is not present. Just use the target_version config file parameter.

Backup

Automatic backup must be disabled during upgrade.

In addition, it is recommended to create a manual backup before you start the upgrade. Enterprise Edition databases will be protected by a Guaranteed Restore Point which is the primary fallback method, however, it is recommended to also have a manual backup. For Standard Edition databases a manual backup is the only fallback method available.

Upgrade

Under the hood the upgrade consists of:

1. Deploy new Oracle Home You should use the same Oracle Home version that was used during the previous precheck.
2. Create guaranteed restore point (Enterprise Edition only) The name of the restore point is prefixed BEFORE#DB#UPGRADE# and the restore point is automatically removed following a successful upgrade.
3. Upgrade using DBUA (incl. an additional precheck) The upgrade is executed using the default settings which does include an upgrade of the timezone file. This is not configurable. If you are upgrading a CDB all PDBs will be upgraded as well. It is not possible to exclude some of the PDBs. Any PDB that is closed when the upgrade starts, will open and upgrade.

While you are upgrading the database it is unavailable. Upgrade requires downtime. How long? As always in IT – it depends! These things matter a lot:

• Number of installed components (select * from dba_registry)
• Size & complexity of dictionary (select count(*) from obj$)
• Some feature/version combinations

These things matter a little:

• CPU
• Disk speed
• RAM

These things doesn’t matter at all:

• Amount of user data

But an estimate is anywhere between 20 minutes to an hour.

After Upgrade

Parameter COMPATIBLE

The COMPATIBLE parameter is not changed by the tooling. You are in full control of this parameter, and should decide when you want to change it to the default value in 19c. Check the documentation to read more about this parameter.

I would recommend that you do it one or two weeks after the upgrade. This preserves the option of performing a database downgrade. But it requires a database restart, so you must be able to tolerate the additional maintenance window. If you can’t tolerate additional downtime, or you don’t care about the downgrade option, you should update COMPATIBLE right away.

In any case this is how you do it:

SQL> alter system set compatible='19.0.0' scope=spfile;
SQL> shutdown immediate
SQL> startup

And always set COMPATIBLE to the default value of the release. Mike Dietrich explain it really good in a blog post.

Update Profile

.bashrc must be updated to reflect the new Oracle Home. There are a few environment variables that should be updated. Either do it manually or you can use sed:

export OLD_HOME=/u01/app/oracle/product/11.2.0.4/dbhome_1
export NEW_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_2
cp ~/.bashrc ~/.bashrc_backup_`(date -u +%Y%m%d-%H%M%S)`
sed -i "s,$OLD_HOME,$NEW_HOME,g" ~/.bashrc
source ~/.bashrc

Backup

Ensure that you have proper backups:

• Re-enable automatic backup, if you want to use it
• Personally, I would add a manual backup taken right after upgrade

Remove Old Oracle Home

You can remove the old Oracle Home. It is no longer supported to use it. You should use dbcli. First, get a list of Oracle Homes:

[root@host]$ dbcli list-dbhomes

Use the ID to delete the Oracle Home:

[root@host]$ dbcli delete-dbhome -i <id>

If you really want you can monitor the progress of the deletion:

[root@host]$ dbcli describe-job -i <id>

Conclusion

It is simple to upgrade a database in OCI to 19c. The upgrade itself is just a click on a button, but for real databases there is a little more to it. But it is still very easy, and most tasks can be executed from the console. If you want to be in better control, or want to minimize the downtime required, you should look into doing the upgrade manually.

I made a video that I posted to our YouTube channel which demos the process.

Other Posts in This Series

• Introduction
• Automated: Upgrade to 19c
• Automated: Upgrade to 19c – The Details
• Manual: 11.2.0.4 to 19c (simple)
• Manual: 11.2.0.4 to 19c (minimal downtime)
• Manual: 12.2.0.1 PDB to 19c
• What about downgrade?
• Transfer Speed