Month: March 2021

If you follow me on Twitter, you’ll know I’ve been doing a lot of upgrades recently. Whenever I mention upgrades, someone comes back with a comment asking me to describe in detail what I’ve done. This always makes me nervous, as every upgrade is potentially unique. What you have to do depends on a number of factors.

• The database version you are upgrading from, and the version you are upgrading to.
• The options you have installed, especially if some are deprecated or desupported in the new release.
• The topology of your system. If you are running single instance on a regular file system, you’ve got a lot less to do compared to someone working with RAC on ASM with a Data Guard standby.
• Are you taking the opportunity to move to new kit and/or base operating system? From OL6 to OL7/8 for example.
• Are you changing OS completely? Maybe you’ve finally made the decision to upgrade from AIX/HP-UX/Solaris to Oracle Linux. 🙂
• Are you planning to convert from non-CDB to the multitenant architecture? You should be!
• How big is the database you are upgrading? I’ve done some small ones with data pump rather than doing a regular upgrade.
• What is your tolerance for downtime? If you have a reasonable downtime window, you can turn everything off and upgrade it, which is a lot simpler than trying to keep the lights on.
• Are there any vendor restrictions that alter how you approach the upgrade?

All of these things, and more I can’t think of off the top of my head, have to be factored in when planning an upgrade, and this is why I say every upgrade is potentially unique.

The types of upgrades I’ve done recently fall into the following general groups, with varying numbers in each group. A number of them have included a move to new kit, because they were running on Oracle Linux 6.

• 11.2.0.4 to 19c non-CDB (Vendor support issues)
• 11.2.0.4 to 19c PDB
• 12.1.0.2 non-CDB to 19c PDB
• 18c PDB to 19c PDB
• 18c PDB to 19c PDB using Data Pump
• 11.2.0.4 to 12.1.0.2 as stepping stone to 19c

The last one may seem odd to people, but this is due to an application dependency issue. The full process for this is as follows.

• Upgrade database from 11.2.0.4 to 12.1.0.2.
• Upgrade application to a version that supports both 12.1.0.2 and 19c.
• Migrate to new kit.
• Upgrade database from 12.1.0.2 to 19c.
• Upgrade application to latest version.

What we are trying to do is make everything as “one size fits all” as possible, to make future upgrades, or moves to the cloud, easier, but that’s not always possible due to other constraints.

I do have a couple of upgrade articles on the site, but they are intentionally basic and I never intend to write anything more detailed about upgrades, because it’s impossible to write something that will satisfy every possibility.

• Multitenant : Upgrading to Oracle Database 19c
• Upgrading to Oracle Database 19c (Non-CDB)

So in summary, there is no one size fits all solution to upgrades unless you have already commoditized all your systems, like the cloud providers do. If you are working with a load of on-prem systems, some of which you have inherited from others, each upgrade will be a voyage of discovery, so don’t ask me for a detailed breakdown of what I did, because I’m just going to say no. There is a reason why there is a great big upgrade manual released with every version of the database!

Cheers

Tim…