Upgrading To
18c / 19c / 20c: What Are My Options?

by Gary Gordhamer, Managing Principal Consultant at Viscosity North America

Upgrading your Oracle databases can seem to be a daunting, or even overwhelming, task. You may believe that your options are constrained. Perhaps previous database upgrades have been limited due to the inability to take downtime for the applications. Let’s discuss some of the options for planning out your database upgrades to 18c, 19c, or even 20c. (Yes, 20c isn’t officially released on all platforms yet, but it will probably be out by the time your database is upgraded.)

Oracle Database Versions: A Cornucopia

Obviously, the first thing to consider is the current pre-upgrade database version and what version is my post-upgrade target. As I mentioned in my first blog post, 11g is now about a decade old, and 19c is the current long-term support release that will be supported until 2023, but remember that 19c is basically 12.2.0.3 “under the covers.” So, let’s start with these versions as examples for our upgrade conversation.

Oracle clearly states supported versions for upgrade in My Oracle Support (MOS) Note 551141.1, Database Server Upgrade/Downgrade Compatibility Matrix. This document extends all the way back to version 7.3.3, so even if you’re on an extremely old release, you do have an upgrade path. Though, some upgrades take more steps then other. Here’s a quick summary of those choices between 11g and 19c:

• If your source database is on 11.2.0.4, you can upgrade directly to 18c or 19c.
• If your source is 12.1.0.2, you can also upgrade directly to 19c.
• If your source is 12.1.0.1, then you can go to 18c directly and then to 19c.

What if you are on a version prior to 11.2.0.4? It gets a bit more complex because upgrading is now a two-step process, involving first upgrading to 11.2.0.4 and thence to either 18c or 19c.  

In my experience, it’s also a good idea to review MOS Note 1352987.1, FAQ : Database Upgrade And Migration, prior to building out your upgrade plans.

Oracle Database Platforms / OS Versions
Another big piece of advice I can give you: Upgrade plans simply cannot ignore corresponding OS platform requirements. Oracle lists OS compatibility in MOS’s Certifications section; here’s a brief summary of which releases are supported on most popular OS platforms:

It’s important not to forget that Oracle deprecated support for 32-bit platforms several years ago, so if your database is still on 32-bit hardware, you’ll have to migrate to newer 64-bit hardware. In addition, Oracle has a long track record of deprecating older OS versions, so if your OS is over five 5 years old, you will need to migrate to a newer OS as well (excluding Windows 2012 and HP-UX).

OS and DB Combinations: Upgrade Considerations
Let’s lay out some examples of upgrade options that account for both the target database’s release as well as the OS that will host that new target database:

• I’m on 11.2.0.4 and I want to go to 19c. You’ll probably need to plan for an OS upgrade at the same time as the database upgrade, and you will have to do both as part of one outage.
• I’m on 12.1.0.2 and I want to go to 19c. You will also probably need an OS upgrade and database upgrade. You can do the OS upgrade in one outage, then do the database upgrade in a later outage, perhaps even one month apart.
• I can’t do the OS upgrade right now, but I do want to do the database upgrade. If your source database is on 11.2.0.4 or 12.1.0.2, there is a good chance that you could complete the 18c upgrade without an OS upgrade.
• I’m on a legacy database version prior to 11.2.0.4. You’ll almost certainly need an OS upgrade and a database upgrade.

There are a few minor exceptions to these OS vs. database upgrade conundrums. In particular, Windows Server 64-bit 2012 and HP-UX Itanium platforms currently have some of the longest lifespans, but you will still need to continue to patch your OS level for those platforms.

Database Technical Upgrade Process
Now that we have some of the heavy planning ideas set, it’s time to consider what possible methods you would leverage during a database upgrade. As with many things Oracle, the answer is that it depends. There are basically three upgrade methods, listed in order of complexity:

• In-Place Upgrade. This involves installing the new Oracle software version and running the database upgrade on the server and storage where it resides.
• Cross-Platform Upgrade. In this scenario, you’d create a new system to host the Oracle database and migrate the data to this new system / version using the appropriate set of Oracle tools.
• Real Time / Rolling Upgrade. This consists of creating a new system to host the Oracle database; setting up logical replication of the database over to the new platform; upgrading the replicated environment in place; and then finally performing a switchover once both the source and target databases are in sync.

A key differentiator is also the impact on downtime for each upgrade method, as this matrix shows:

Back to our “it depends” conundrum, there is a lot here to consider that depends on your current source and target database environments. For example:

• How large is the source database?
• What technology do you have to transfer the data between systems?
• What type of hardware is the source and target database running on?
• How fast is that hardware?
• What version of database and OS are you currently running?

Multitenancy: The Elephant In The Room
Oracle 12c introduced a major new feature – multitenancy – in 2013, but even today many Oracle DBAs view this as uncharted territory.  It’s important to understand this technology now as Oracle has already announced that 20c will require migration to multitenant architecture and that non-CDB databases will be deprecated. 

Does that mean you have to convert to multitenant right now, even on 19c?  The short answer is no – you can continue to create, manage, and use non-CDBs in 19c. Though, you’ll be losing out on new technical features and one of the best licensing deals Oracle has offered, because Oracle has also extended multitenant usage to allow for three (3) PDB’s with no additional licensing.  

That said, here are a few things to consider:  First, making the transition to multitenant can be a pretty big technical change for your database staff, especially if they’ve not been upgrading their skills and technical orientation through training courses and even simple experimentation.   Taking on the additional challenges of using PDBs within CDBs for the first time during the upgrade process can lead to all sorts of issues while also tackling the differences between releases.

Secondly, once you convert a non-CDB to a new CDB/PDB environment, there is no easy way to revert back to a non-CDB.  While it’s not 100% irreversible, it can require a lot of extra effort and database downtime to revert back.  

One More Thing … 
So far I’ve outlined a plethora of options for upgrading your databases to 18c / 19c / 20c as well as your OS platform(s), but one crucial consideration I’ve yet to broach is the application workload your database supports. 

Your application will generally drive the path and type of upgrade you choose.  Some commercial off the shelf products like E-Business Suite or JD Edwards will only support specific types of upgrades.  Sometimes outages for upgrades are inevitable due to application level patches or changes that are required.  Other applications might be so simple or straightforward that upgrading requires that you just copy the data from the source database to the target.

It’s critical to put database upgrade options in context to your application, and here are a few final questions to help you:

• Does my application have specific Oracle database version or migration tool requirements?
• How much downtime can I afford for my upgrade?
• Have I properly funded the team with training, tools, and equipment to support those uptime needs?
• Is my team trained and fluent with the upgrade tools required for the path we have chosen?
• Will I need to procure or build out a new platform for the upgrade?
• Can my current platform support my system for four more years?

This can all be kind of daunting.  But as I said in my previous blog post: If not now, then when? Why not invoke the spirit of Carpa Indicia - Seize the Data!  Start your upgrade plans now, make it a priority to spend the time and effort needed to get your application and database teams up to date, and pull together the plan and funding needed. 

Most of all, understand where you are headed … and why.

About the author: