Patching recommendations: Which route is the best? RUs, MRPs, n-1??

Be aware, this is a longer Monday blog post. Upfront, I am not the master of patching. And I clearly see that many of you struggle with the current situation. Not only regarding Oracle software but I guess, this extends to almost every software or OS. Since I get asked almost daily about the ideal approach, and since we discuss these topics internally across the tech teams as well, I thought I would share here my personal Patching recommendations: Which route is the best? RUs, MRPs, n-1??

Photo by Ben Wicks on Unsplash

Prelude

Two important things I’d like to make clear upfront.

At first, I am not the ultimate patching authority. What I think and propose may be great for one, and may not work for somebody else. And I am not attempting to cover the entire software stack. My glasses are clearly “Oracle database glasses”. Certainly, I know that you have other software in use, either from us or from other companies or in-house-written software as well.

In addition, I honestly understand also all the lacks and limitations. I know that it is not helpful or ideal when we delay or revoke an RU, and it takes extra days to release a new drop. You can read about some examples on the blog already. Let’s not discuss the past, there is nothing I could say to make this look beautiful. But bare with me that we are aware of this – and we try to improve the processes constantly to avoid such unfortunate situations.

Don’t shoot the messenger – this is a recommendation, and I am not in charge of the patching process.

Of course, we all at Oracle fully understand the pressure you have. Whether you are a cautious DBA or pushed by regulators and security auditors. We try out best to deliver especially one-off patches as quickly as possible.

You must upgrade to 19c or 26ai. Period.

Just this and the last week I did user group presentations with up to 300 people in the room. And a quick poll for “who is using anything older than 19c” reveals quickly that not everyone is on 19c or 26ai yet. Are you on 19c or 26ai already entirely??

If not, this is dangerous.

You all are certainly fully aware of our announcement I covered in Patch your database against AI-enabled cybersecurity threats. You must patch more frequently. The danger is not that modern LLM models find security loopholes – the danger is that everyone can build an exploit easily without any knowledge about proper coding.

We humans tend to act as described in the Ostrich effect – or head-into-the-sand. In German, it sounds even more lovely: “Vogelstrauss-Politik“. Instead of facing the challenge and improving the process, we keep things as they are since changing anything is complex and involves a lot of work. Especially when it comes to more frequent software patching, we often are bound to many constraints and restrictions.

But when you look for instance at the risk matrix for 19c, 21c and 26ai from July 2026, you may notice in the right-most column it mentions 19c and 26ai only. Now while this sounds obvious to some, let me explain in reverse it means also: Fixed and listed issues are most likely present in your older database releases as well.

Which leads to the truth, everything listed here could be potentially broken as well in your ancient 11.2.0.4 or 12.1.0.2 databases  – and I don’t even want to speak about your antique 10g or 9i databases. For 11.2.0.4, 12.1.0.2 and 12.2.0.1 you could get an Upgrade Support agreement where we may fix some of the issues.

But in essence, there is only one thing I can say. And I am not saying this as the guy who loves upgrades.

You MUST upgrade to Oracle Database 19c or Oracle AI Database 26ai as quickly as possible.

Period. No further discussion.

If you don’t complete this as quickly as possible, you failed. Sorry to be that rude. And of course, I am aware of legacy applications, I know about older app versions not updated and not certified for 19c. But let’s talk frankly here. 19c is out since 2019. This was iPhone 11 and 11pro. I guess not many of you use a seven year old iPhone anymore. There were enough chances to upgrade to 19c. Remember that you could use 19c with COMPATIBLE=11.2.0 if needed for backwards app compatibility as an escape route.

Whatever you tell me now about constraints, the application teams, versions, certifications and so on, I fully understand. There is always a good and legit reason, and often many more. I don’t take this as an excuse but rather an explanation.

Still, somebody hacking into your database(s) and stealing your data may NOT pay attention to the reasons why you haven’t upgraded yet.

AutoUpgrade makes your upgrade(s) a walk in the park. We have seminars about it, it was never easier. Not saying that there are no issues. Sometimes there are some. But you must tackle this NOW. This blog is called Upgrade Your Database – NOW!. And it was never more true and valid as it is today. Mind my words.

Why does n-1 not work anymore?

Let me clarify at first what I mean with n-1.

For a long time, the recommendation and best practice for many customers was going with a n-1 patching strategy. This refers to the following:

• Release Upgrade 19.32 got released in July
• You start now utilising the previous – n-1 – Release Upgrade 19.31 from April since the perception is that 19.31 is considered to be well seasoned, tested by many others already, and existing known issues listed in KB188772 (formerly known as 555.1) or covered by the MRP3 for 19.31.

Why is this not a good strategy anymore?

Reality bites.

On one hand, many of you need one-off fixes and merge patches on top of an RU. This is reality, and those fixes aren’t available all the time at day 1 of the RU release. Many of you also aren’t aware that we release a lot of the fixes upfront based on a selecting considering download numbers. For instance if the fix for famous Bug 29213893 – [QRY OPTIMIZER] DBMS_STATS Failing With Error Ora-1422 When Gathering Stats for User$ Table (which is not RAC rolling and can’t be included into an RU right now) has been downloaded at least once, it will be pre-produced and published together with the RU at release date. We do this with thousands of fixes proactively.

But merges are often delivered on request only. Thus, you must upload your opatch lsinventory of the day of the RU release, and then request the missing patches. Producing these fixes may take a bit. So, we fully understand that you often can’t start testing on day one of the initial RU release. Be assured that we understand this, and we try to improve this on our side as much as possible to deliver these patches quicker, or – ideally where possible – include them into a future RU.

Now, let’s assume it takes 3 weeks until you have received all necessary fixes. You can test now with the RU plus the additional patches you need.

Many customers work with a multi-stage testing, meaning: You will ship this to Test/Dev at first. Let me revisit my example from above. The RU got released on July 22, If you requested one-offs and merges you required on top of the July 23 RU, let us assume you received everything by Aug 12. This would have meant that you roll it out to Test/Dev on the weekend of Aug 15. Since nobody loves working on weekends, you had fully automated it.

Let’s assume you did all this. Now, the application teams will need at least 1 week to test and verify and sign off. By August 19, you would be ready to rumble on Prod. But we released already a new MRP with some security fixes on Aug 18. Ideally, you would quickly include those into your gold image before you roll it out into Prod. But in summary, this process at best ideal case has taken a total of 4 weeks. We try to shorten this from our side. But you need also rapidly request the fixes you need right away when the RU gets published.

In my team we load the RU and the MRP as quickly as possible into oradiff. Use the “Search Fixes” functionality to check whether the fixes you needed in the previous RU are now included. We publish MRP content as well in oradiff.

Why does n-1 not work anymore?

See the timeline above. If you follow this track and try to do this exercise with n-1, you are in danger.

• In July 2026 you take 19.31 from April 2026
• You request the one-offs and merges
• This takes again potentially 2-3 weeks
• You roll it out to Test/Dev in mid-August
• You plan to go-live end-of-August, and it many cases it will become September
• The best you could do now is adding MRP4 from August or MRP5 from September to consume the security content we ship with MRPs (or CSPUs)

Sounds still reasonable, right? But read on …

RUs are the primary vehicle to deliver security fixes

Now we talk facts. You can easily use oradiff.oracle.com to check and compare the security fixes shipped with an RU vs an MRP. See in How many fixes are you missing? how to check quickly for security fixes included. And be aware that oradiff.oracle.com lists also CVEs covered per MRP (“Included Fixes” ==> “List in CVEs”).

When you compare now the content security-fix-wise between the July 2026 RU and the 4th MRP for the previous RU, you will find out:

oradiff.oracle.com – comparing 19.31 with MRP3 from July 2026 to 19.32 from July 2026 released at the same time

First of all, you will miss 656 fixes between 19.31 + MRP3 from July 2026 compared to 19.32 from July 2026 with no MRP available yet. But let us look at the security content. You can easily identify it by adding a search pattern “Fix for Bug”.

The result may surprise you: You are missing 515 security fixes in July 2026 when you go with MRP3 on top of 19.31 compared to 19.32.

Why is this?

The primary vehicle to deliver security content was and is the Release Upgrade – and not the MRP or the CSPU (for non-Linux environments). The MRP (or CSPU) is a helper in between two RUs to deliver the most important content, i.e. security fixes with a very high CVE score. But certainly, an MRP (or CSPU) is not delivering ALL security fixes being made available.

Therefore, you may need to adjust your processes and follow my Patching Schedule Recommendation below.

Patching Schedule Recommendation

This is what I would recommend to you. Of course, this does not cover the time to request one-offs or merges. But as written above, we do our best to be faster and deliver quicker, or include the patches we can include into RUs where possible.

Patching Schedule Recommendation and Best Practices

So, the recommendation is:

• You take the current RU, and not n-1
• You apply the most recent MRP (or CSPU) on top available at time of deployment
• Once the next RU is available, you switch as quickly as possible
• And again, at day of deployment, you add the most recent MRP (or CSPU) on top

I personally see no other way to stay compliant and move forward in these days. Of course, I know that this is tough, and you won’t achieve this from today on. But let’s try to optimize processes on our side as well as on your side. You must make the application teams aware as well. There is no other option for them, too.

The days when the application could delay a rollout of an important database patch bundle are history.

One final thought

In addition to all this above, I’d like to give you one final recommendation. Many customers I met over the years operate a wild zoo with various database releases and RUs. As said before, you must upgrade to 19c and/or 26ai as these are the releases where we deliver all those fixes.

But you also must use only 1 single RU for each of them.

Don’t have 19.28, 19.29, 19.30, 19.31 and 19.32, and at best with various MRPs on top.

Have one single current RU, and try to go with one single MRP. As you may not be able to switch instantly on a single given day or week, you may have multiple various MRPs. I don’t see this as a bigger problem. But having the same current RU everywhere is essential.

Further Links and Information

• (KB188772) Oracle Database 19c and Oracle AI Database 26ai Important Recommended One-off Patches
• Clarifications about CPUs, CSPUs, MRPs and RUs
• More clarifications about CPUs, CSPUs, MRPs, RUs
• RU 19.31 has been put on hold
• Patch your database against AI-enabled cybersecurity threats
• Accelerating Vulnerability Detection and Response at Oracle (3 min read – April 29, 2026)
• Take Action Today: Protect Your Oracle Database Against AI-Enabled Cybersecurity Threats (1 min read – April 30, 2026)
• COMPATIBLE in Oracle 19c
• oradiff.oracle.com
• How many fixes are you missing?

–Mike