One of my client is on 12.1 and since the support for 12.1 has ended we started planning the upgrade of this database. During the research I did before the upgrade I found some things that were very important and affected our decisions and the upgrade process.
Choosing Version
Choosing version is the first step when thinking about upgrading. It’s easy to say “let’s upgrade to the latest one”, but it’s not always to correct decision. In this case we are using Oracle Streams (yes, still). When I did my research I found out that Oracle 18c will be the last release to have Streams, so obviously we can’t upgrade to 19c.
Requirements of the New Version
Sometimes the target version has specific requirements. As this is RAC, when I read about 18c RAC I realized that 18c GI requires the OCR and voting disks to be on ASM. In this case we are using NFS for everything, so adding an ASM on top of NFS (note 1620238.1 explains how to do this) meant adding complexity (on the upgrade process and managing this afterwards). Luckily Markus Michalewicz saw my tweets and suggested to upgrade the GI to 19c and the DB to 18c (as 19c doesn’t have this requirement for OCR/voting disks).
The Upgrade Process
In a different upgrade project I have a standby database, so it was important to make a few decisions about that (for example, are we upgrading the standby at a same time or disconnecting the standby and keeping it a few days as a fallback?). Another thing is to check if there are any known issues during the upgrade. Sometimes there are recommended patches for the source database before the upgrade, so it’s important to install them in advance and not hit issues during the upgrade itself.
Upgrade Plan
Before you start the upgrade, read about the process and write a detailed procedure. This is a very important step for 2 reasons:
- When you are writing a procedure, you are forced to think about each step of the process. When I wrote such procedures in the past, in many cases I realized that there are more things to think about and decide. The fact that I wrote the procedure helped me cover almost any aspect of the system related to the upgrade
- Upgrades are done under a lot of stress and sometimes at night. I like to get to the upgrade as ready as possible and with as little “judgment” as possible. At 3am I don’t want to think about the next step, I want to read it from the procedure and follow it. This is why I add to the procedure even things like “check the log”
Post Upgrade
There are sometimes known issues here as well (examples from Mike Dietrich: _cursor_obsolete_threshold and _rowsets_enabled, the second one I hit and told about it here). Again, it’s much easier to set them in advance, but even if not, if you have a good testing environment you might hit this issue and fix it before going live.
Don’t Forget
Don’t forget to add to the upgrade procedure the things you need to take care of after the system is upgraded and running. Adjust your backups (and check that they work the next time it’s executed), make sure your monitoring works, set the environment variables to the new environment, check your scripts, and think about any other thing that might need attention.
Summary
When thinking about upgrading your database/environment here are a few points to think about and research:
- Check the features you’re using and make sure they are supported/exist in the target version
- Check requirements for the new version and see if you meet these requirements. For example, 19c on Linux requires Linux 7. If your existing database is on Linux 6, you should upgrade the OS first
- Check recommended patches on the source database before upgrading (for example note 2414935.1 for 18c)
- Read about known issues in the new version and try to follow best practices
- Build a detailed plan for the upgrade based on the research
- Test the upgrade and your procedure on a temporary environment and adjust the procedure accordingly
Did I miss something? Do you have any addition or comment? Please add them below, I’d love to hear what you do before you plan to upgrade your database.