More clarifications on RUs, MRPs and CSPUs

There are questions coming in from time to time, and I see that not everything can be always covered in an FAQ document. But we try our best. And sometimes, there are questions even I need to think twice before I answer. Here is the newest for More clarifications on RUs, MRPs and CSPUs.

Photo by Larry Nalzaro on Unsplash

What do you need to read before?

Don’t even read further if you haven’t read already:

• MRP, CSPU, CPU, RU – some clarifications
• FAQ7719 – Introducing Critical Security Patch Updates (CSPUs) and FAQ

The latter MOS FAQ is incredibly hard to find via the search – but it is worth a read.

Maybe the topics I am listing here (which all got raised via the blog or via email) will be added to the FAQ soon, too.

Can you request security fixes or MRPs on 19.29.0?

I know that patching as quickly as needed is very hard. And we are fully aware of the fact that requesting and receiving one-off and merge patches on top takes a little bit, too. The latter may slow you down in addition to your own process, testing requirements, application constraints, and so on. Therefore, I understand if somebody says: Look, we are still on 19.29.0, and we plan to move to 19.32 in late September when we received all content, completed our testing etc.

But you need to keep in mind that MRPs (with one exception) and CSPUs are given only for the current and the previous RU.

See this graph from my blog post:

6 MRPs on top of an RU

This means, while I am writing this blog post on Aug 24, 2026, you will get an MRP (or CSPU) on top of 19.32 and 19.31 but not on top of 19.30 or 19.29 anymore. The same applies to Oracle AI Database 26ai where we are on RU 23.26.3 – and delivered MRPs on it as well as for the previous RU, 23.26.2. But not on top of older RUs.

In addition, please understand and be aware that the vehicles to consume security fixes are at first:

• Release Updates
• In addition on top to stay current: MRPs or CSPUs, depending on version and platform

But security fixes are very rarely released as one-off fixes. Thus, you must apply the RU, and then going forward use the MRPs or CSPUs until the next RU gets released.

Can I still stay N-1?

In relation to my paragraph above, there are often discussions whether you receive the same security content when I compare the current RU with the previous RU and the MRPs on top.

And the clear answer based on my view is: No.

Let us take a current example and compare the plain 19.32, the current RU with 19.31 with the matching July MRP3. oradiff.oracle.com is a great helper here.

• 19.31 => 19.31 with MRP3 contains 16 additional fixes, 12 of them have “Fix for bug” in the subject (security fixes)
• 19.31 => 19.32 contains 671 fixes on top of 19.31, and 527 (!!) of them tell you “Fix for bug” in the subject

So, I think this has answered it by itself. When you stay N-1, the previous RU plus the most recent MRP or CSPU on top, you only consume a fraction of the available security fixes.

As I mentioned above, the main vehicle to deliver security content are clearly RUs. Therefore, you must stay current with RUs, and you should apply the monthly MRPs or CSPU on top. But you should not stay with the previous RU anymore. This is also the reason why our exec management has been decided to password-protect older RUs.

How can I find if an MRP is applied?

This question is there from day 1 when we introduced the MRPs. Scroll down to the last paragraph here,

• Patching Process Changes with MRPs

and you will see that this question has been raised shortly after MRPs got introduced in 2023.

Unfortunately, there is still no way to tell from looking at your inventory whether an MRP has been applied. This is an old example, and the number of fixes may not be this high, but you can only see the one-off patches. There is no one-line-entry telling you an MRP or CSPU has been applied as it happens for instance with the Data Pump Bundle Patch.

$ORACLE_HOME/OPatch/opatch lspatches

35246710;HIGH DIRECT PATH READ AFTER 19.18 DBRU PATCHING
35213579;MERGE ON DATABASE RU 19.18.0.0.0 OF 35037877 35046819
35162446;NEED BEHAVIOR CHANGE TO BE SWITCHED OFF
35160800;GG IE FAILS WITH ORA-14400 AT SYSTEM.LOGMNRC_USER AFTER ORACLE DB UPGRADE TO 19.18DBRU
35156936;ORA-7445 [KFFBNEW()+351]  AFTER CONVERT TO ASM FLEX DISKGROUP
34974052;DIRECT NFS CONNECTION RESET MESSAGES
34879016;ALL SESSIONS HANG DUE TO INST_RCV BUFFER IS NOT GETTING WRITE PERMISSION
34871935;SBI  QUEUE BUILDUP - SESSIONS SPIKE WITH GC CURRENT REQUEST  (6-DEC-2022)
34861493;RESYNC CATALOG FAILED IN ZDLRA CATALOG AFTER PROTECTED DATABASE PATCHED TO 19.17
34810252;SPIN OFF FOR BUG 34808861 [ORA-00600  INTERNAL ERROR CODE, ARGUMENTS  [KFDS_GETSEGREUSEENQ01] TERMINATED ALL DB INSTANCES
34793099;STRESS FA CDB CREATION FAILS ON 19.17 WITH THE ORA-00704  BOOTSTRAP PROCESS FAILURE WHILE OPENING PDB$SEED
34783802;PARALLEL QUERY ON PARTITIONED TABLE RETURNS WRONG RESULT
34557500;CTWR CAUSED MULTIPLE INSTANCES IN HUNG STATE ON THE RAC STANDBY DATABASE
34340632;AQAH  SMART MONITORING & RESILIENCY IN QUEUE KGL MEMORY USAGE
33973908;DBWR NOT PICKING UP WRITES FOR SOME TIME
32727143;TRANSACTION-LEVEL CONTENT ISOLATION FOR TRANSACTION-DURATION GLOBAL TEMPORARY TABLES
31222103;STRESS RAC ATPD FAN EVENTS ARE NOT GETTING PROCESSED WITH 21C GI AND 19.4 DB
34972375;DATAPUMP BUNDLE PATCH 19.18.0.0.0
34786990;OJVM RELEASE UPDATE: 19.18.0.0.230117 (34786990)
34765931;Database Release Update : 19.18.0.0.230117 (34765931)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

I know that customers filed Enhancement Requests already, and I am confident that we will see some improvement soon.

When you look at any MRP readme, you will see that this is the reason:

2. Apply all MRP content in an offline manner using “opatch napply”.

When you apply single patches with an “napply” command, you get single entries for each of them in the inventory.

MRP check in AHF?

Let me add here a hint a customer gave me, and to be frank, I was not aware of it. He pointed out that Oracle AHF (Autonomous Health Framework) is able to verify whether an MRP has been applied. I checked, and it is true.

As far as I could find out, AHF 23.3 added MRP reporting. The observable mechanism seems to be:

1. AHF has its own updateable MRP metadata/catalog
2. The catalog maps an RU and MRP level to the expected one-off patch IDs
3. AHF reads the Oracle home’s OUI/OPatch inventory
4. It compares the expected patch set with the installed patch set and reports installed/missing patches

I am not 100% certain if the above is an really absolutely precise description but as of now, it seems to be the only way to check whether an MRP has been applied.

Can you patch the client install with an MRP?

This is a tough one since I basically never patch my client install. Why not?

Well, I switched to the Instant Client a long time ago, and I download the newest version which is supposed to be patched. But it is actually a very legit question a colleague raised last week. I had to think twice but I assume that you should be able to patch your client installation with an MRP as well.

Why?

Well, you can apply an RU to your client installation. And I don’t see a reason why you shouldn’t be able to patch the client install with an MRP then.

But there is one rule on this blog:
I always write only about things I tried out by myself – or somebody in our team has tried it out. In this case, I have to confess that I didn’t try it out. If somebody did already, let me know. Otherwise, I will do this by myself as soon as time allows. But I realized that the README does not tell anything about client install. It mentions that you need the base RU the MRP has been built for, and that you can use the MRP to patch your database home.

Especially the latter made me wonder:

• This MRP can only be installed to an Oracle home that has Oracle Database Release Update 19.32.0.0.260721.
• This MRP is applicable to the Oracle DB Home

But I will find out soon.

Can I apply an RU on top of an MRP?

This is an interesting one as well. A customer asked this on the blog the other day – and you sort-of-can.

Let me differ at first:

When you patch in-place (what we discrecmmend) than you must deinstall the MRP at first. For example, you have 19.31 RU with MRP3, and then you want to apply 19.32 RU into the same home. Since MRPs are one-off patches (same as the Data Pump Bundle Patch) you must remove them from the home at first before you can apply the 19.32 RU on top.

When you patch out-of-place (what we highly recommend) then you won’t have such issues. You prepare your new home with 19.32, and you don’t care what has installed in the old/previous home. You simply let datapatch do the cleanup work. It will sort it out for you, and you will have less hassle.

Further Links and Information

• MRP, CSPU, CPU, RU – some clarifications
• FAQ7719 – Introducing Critical Security Patch Updates (CSPUs) and FAQ
• (FAQ2283) Introducing Monthly Recommended Patches (MRPs) and FAQ
• (CPU302) Critical Security Patch Update (CSPU) August 2026 for Oracle Database Products
• Patching News: RURs are gone – long live MRPs
• Patching Process Changes with MRPs
• Password-protection of older RUs

–Mike