What Oracle Database Patches Do I Need?

A few years ago I wrote the post All You Need to Know about Oracle Database Patching, and I also presented a presentation about this topic a few time. But over time I learned new things and ran into new problems, so it’s time to revisit this topic and add some more info about which Oracle database patches we need and how to plan the patching process.

Types of Patches I Need

I wrote about this in the post I mentioned above, so I’m not going to get into this here, but as a general note you should use the latest RU or RUR for the database (and GI if you use it). You might also need the OJVM patch (see note below), and the tricky part – one-off patches on top of the RU/RUR.

One-offs Patches on top of RU/RUR

After you decide you need to install a new RU/RUR, some one-off patches might be required:

1. Known issues – these are problems with the RU/RUR and there might be instructions to follow if you hit these issues, or patches you should install to avoid them.
2. Recommended patches – after you install an RU/RUR, there still might be unfixed issues that are important enough for Oracle to recommend patching them as well.

I’ll discuss the entire process of how to plan all the patching later in this post.

Relevant MOS notes

There are three notes important for finding all of this information:

1. Note 1227443.1 – this is the master note for all the known issues in all Oracle versions. This note will lead you to the relevant “known issues” note for your specific version and RU/RUR.
2. Known issues specific note – From the previous note you should get to this note (for example note 19202201.9 for 19.14). This is the note that contains the actual one-offs patches we need to consider installing, so create a list for patches and add these patches to the list.
3. Note 555.1 – this note contains all the recommended patches for all RUs of 19c (couldn’t find an equivalent one for 21c). Find the relevant RU and add all the relevant one-off patches to the list you created in the previous step.

Now you should have a list of one-off patches you should install on top of the RU/RUR. But it’s not over.

Finalizing the One-off Patch List

Now the Sisyphean task begins.

With the list you’ve got (and it might be quite large, I needed to install 19.12 not too long ago and ended up with a list of more than 60 one-off patches), you need to figure out which ones you ACTUALLY need:

• Some patches appear in both notes (known issues and recommended patches), so you should eliminate duplicates first.
• Some patches are for RU or RUR only, so if you don’t install this specific one, you can skip them (for example, you install 19.12 and a patch is only relevant to 19.11.1).
• Some patches are specific to a certain environment like specific OS, RAC, or ASM. If you don’t use it, you can skip the patch.
• Some patches are for a specific feature like partitioned tables or data pump. If you don’t use these features you can skip these patches.

Finding this info might require some digging. I usually prefer to reduce the amount of patches (within reason), so I go and read the bug notes to figure out if I need this patch or not (for example, in the 19.12 patch installation I did, a few of the patches were for systems with NUMA enabled, but we don’t enable NUMA, so I didn’t install these patches).

I understand that Oracle usually recommend installing all patches “in case you will use these features in the future”. However, for long running familiar systems, I sometimes knowingly skip ones related to features that the system will never use.

Now there are still two more potential issues with the updated list:

1. Patches might not be available – this happens quite often, the patch is either unavailable for your specific version, or your specific system. You’ll figure that out when you start downloading the patches on the list.
2. Patches can conflict with each other – this is much more difficult to know in advance. I suggest installing the home well in advance or try it out on a different machine, just to find conflicts.

With both of these problems it’s best to open an SR and request the relevant patch (either the one that doesn’t exist, or one that doesn’t conflict with another). With conflicting patches there is also the option to skip the less important one, or implement a workaround for one of them (if available) and install the other one.

OJVM Patch

OJVM patch was always tricky. In the past it needed “startup upgrade”, later you could skip the “upgrade mode” in some situations, while in others you could even install it in a rolling matter. Mike Dietrich wrote a good post about it. But what I wanted to emphasize is that starting with 21c, OJVM can be upgraded in a rolling way without any restrictions and it was also incorporated in the RUs. So there is no need to patch OJVM separately anymore, just install the RU and the OJVM is patched with it. FINALLY!

Plan Summary

To sum the process up, this is what you should do before starting to patch your Oracle database:

1. Decide which RU/RUR you are going for.
2. Check the known issues note (based on a link from Note 1227443.1) and start a list of one-off patches.
3. Add to the list the relevant patches listed in the recommended patches list (Note 555.1).
4. Go over the list and eliminate patches that are duplicates, or irrelevant for your environment/system.
5. Download all patches from the list and open SRs for those who can’t be found, so Oracle can create them for you.
6. Create a new home with the target version and make sure the patches don’t have any conflict. If they do, open an SR and request a new version that doesn’t conflict.
7. Install test environment and upgrade it before getting to production.

I hope this will help you next time you plan to patch your database. If you have any comments or additions, please add them in the comments below.

If you want to get updates when I publish a new post, subscribe here: