You may have read my previous blog posts about MRPs (Monthly Recommended Patches). And today I did a quick check with Rodrigo. We both were a bit surprised to have the MRP3 for 19.17.0 add a lot of fixes to a standard RDBMS installation. So we were investigating a bit further. As a teaser, read on to see that MRP3 for Oracle 19.17.0 adds an interesting surprise.

Photo by David Brooke Martin on Unsplash
How did we find out?
The MRP3 for Oracle Database 19.17.0 got released just a week ago. You can navigate to it via MOS Note: 888.1 or directly to patch 34935010. It is available on Linux only.
Actually, the README delivered with the MRP3 for 19.17.0 is interesting. And certainly, at least I didn’t study the README carefully upfront start-to-end. But even if I would have had read it, I may have missed or simply ignored an important detail:
MRP version | Bug Fixes |
Database MRP 19.17.0.0.230117 | 33838019, 34816203, DB MLR 34938232(34808536, 34697861, MLR 34789241), OCW MLR 34953559 (MLR 34882612, 34002170) |
Database MRP 19.17.0.0.221220 | MLR 34789241(34060122, 33896423, 34310304, 34377917, 34485380, 34562023), 34715072, 34545238, 32295794 |
Database MRP 19.17.0.0.221115 | 33896423, 34333986, 30691454, 34538232, 34574048, 34366627, 34724125 |
Do you spot the interesting surprise? In the 2nd row of the above table in the right column “Bug Fixes” you will see:
- OCW MLR 34953559 (MLR 34882612, 34002170)
Now to be frank, even if I’d had paid attention to the README, I would not have been worried. But when Rodrigo and I saw that there are over 1500 fixes in this MRP3 for 19.17.0, we were a bit surprised.
Applying the MRP3 for 19.17.0
So let me quickly apply the MRP3 without all the extra checks usually necessary. You can read about the additional checks in my previous blog posts for the MRP1 and the MRP2 for 19.17.0. please.
$ $ORACLE_HOME/OPatch/opatchauto apply -binary /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010 -oh /u01/app/oracle/product/19 -target_type oracle_database Oracle Home : /u01/app/oracle/product/19 OPatchAuto binary patching Tool Copyright (c)2014, Oracle Corporation. All rights reserved. OPatchauto Version : 13.9.5.0.0 Running from : /u01/app/oracle/product/19 opatchauto log file: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/opatchauto_2023-01-26_22-55-06_binary.log Target type : oracle_database Patch selected: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010 Analysing this list of patches : [/media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/33838019, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34938232, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34545238, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34724125, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34366627, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34538232, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34333986, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34715072, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/32295794, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34816203, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34574048, /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34953559] ... Analysis completed. Applying the patches ... Patches successfully applied. ==Following patches were SUCCESSFULLY applied: Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/32295794 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/33838019 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34333986 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34366627 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34538232 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34545238 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34574048 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34715072 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34724125 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34816203 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34938232 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log Patch: /media/sf_TEMP/19/MRP/p34935010_1917000DBRU_Linux-x86-64/34935010/34953559 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2023-01-26_22-55-07PM_1.log opatchauto SUCCEEDED.
That doesn’t look unusual either.
The README tells me further:
- Note: MRP 19.17.0.0.230117 does not include any SQL changes and hence datapatch does not need to be run post installation. This may change for future MRPs.
Hence, no datapatch needed.
So far everything looks as normal as before.
So what is the surprise then?
At first, importantly let me explain that we are internally in agreement that this shouldn’t be the case. I don’t know yet how this will be solved (re-release of MRP3, ignore it and wait for MRP4 instead – I will let you know as soon as I know).
Let me start comparing the inventory before and after.
This is the inventory before I applied the MRP3 to a clean 19.17.0 (and it had a 19.18.0 OJVM gotten already):
$ $OH19/OPatch/opatch lspatches 34786990;OJVM RELEASE UPDATE: 19.18.0.0.230117 (34786990) 34734035;MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187 34419443;Database Release Update : 19.17.0.0.221018 (34419443) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
And this is the inventory after:
$ $OH19/OPatch/opatch lspatches 34953559;OCW Interim patch for 34953559 34938232;MERGE ON DATABASE RU 19.17.0.0.0 OF 34789241 34697861 34808536 34816203;FAILURE OF SETTING DATA GUARD BROKER PROPERTY FASTSTARTFAILOVERLAGLIMIT TO LOWER THAN 30 34724125;Fix for bug 34724125 34715072;Fix for Bug 34715072 34574048;POD EEHO-DEV5 UNABLE TO SWITCHOVER ODS DB 34545238;STABLE_E2POD LGWR WAITS FOR EVENT ENQ CF - CONTENTION FOR 532 SECS. KRBM.C 13489 34538232;AFTER GI PATCHING AND DB UPGRADE TO 19.16 SESSIONS ARE CONSUMING TEMPTABLESPACE. 34366627;DNFS IO HANG DURING STRESS TEST 34333986;AIM ORA-600 [KTUSCV1 CV BUF TOO BIG] - KTUSCV1 33838019;DATABASE HANG WITH RDBMS IPC MESSAGE ENQ KO - FAST OBJECT CHECKPOINT CKPT 32295794;FIX BUG IN KSIPC STORAGE IPS DISCOVERY 34786990;OJVM RELEASE UPDATE: 19.18.0.0.230117 (34786990) 34734035;MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187 34419443;Database Release Update : 19.17.0.0.221018 (34419443) OPatch succeeded.
That is a bit hard to digest. So let me list only the additional new fixes.
Removing the fixes which are identical in the before/after listing, it boils down to “before“:
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
and “after“:
34953559;OCW Interim patch for 34953559 34938232;MERGE ON DATABASE RU 19.17.0.0.0 OF 34789241 34697861 34808536 34816203;FAILURE OF SETTING DATA GUARD BROKER PROPERTY FASTSTARTFAILOVERLAGLIMIT TO LOWER THAN 30 34724125;Fix for bug 34724125 34715072;Fix for Bug 34715072 34574048;POD EEHO-DEV5 UNABLE TO SWITCHOVER ODS DB 34545238;STABLE_E2POD LGWR WAITS FOR EVENT ENQ CF - CONTENTION FOR 532 SECS. KRBM.C 13489 34538232;AFTER GI PATCHING AND DB UPGRADE TO 19.16 SESSIONS ARE CONSUMING TEMPTABLESPACE. 34366627;DNFS IO HANG DURING STRESS TEST 34333986;AIM ORA-600 [KTUSCV1 CV BUF TOO BIG] - KTUSCV1 33838019;DATABASE HANG WITH RDBMS IPC MESSAGE ENQ KO - FAST OBJECT CHECKPOINT CKPT 32295794;FIX BUG IN KSIPC STORAGE IPS DISCOVERY
Still, this is not unexpected. My system had no MRP yet. And above you’ll see a list of the fixes being added now with MRP3. But the only thing I wonder about is the replacements of:
- 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
with:
- 34953559;OCW Interim patch for 34953559
You may or may not wonder except for the case when you may have no RAC and wonder why an OCW merge patch has now been installed into your single instance home replacing the standard OCW 19.3.0 every 19c home has by default.
It is at least questionable whether you need an OCW bundle patch in a single instance database home when no GI, ASM etc. are used.
What you don’t obviously see is the number of fixes you’ll add with this change.
Let me move a step further. Now I take the patch number 34953559 of the “OCW Interim patch” and put it into the MOS patch search screen. It will give me this result:
No joke, this is the entire OCW Release Update 19.17.0 which has been packaged into the MRP3.
It adds an additional 1566 fixes compared to a fresh 19.17.0 home just by adding “OCW Interim patch for 34953559“.
Will napply help?
This was a question on the blog before when I complained that I have to use opatchauto for the MRP instead of opatch. Customers told us that this breaks their automation scripts or runbooks. So my thought here quickly was: Let me just exclude fix 34953559, the OCW bundle.
Unfortunately, as you see below, this isn’t a workaround since the MRP has been delivered as a SYSTEM patch, not as a bundle such as the Data Pump Bundle Patch.
$ $ORACLE_HOME/OPatch/opatch napply -id 32295794,33838019,34333986,34366627,34538232,34545238,34574048,34715072,34724125,34816203,34938232 Oracle Interim Patch Installer version 12.2.0.1.36 Copyright (c) 2023, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.36 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-01-27_08-28-31AM_1.log This command doesn't support System Patch. Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-01-27_08-28-31AM_1.log OPatch failed with error code 21
Conclusion
I don’t want to judge whether this is good or bad. But as I wrote above, we are in agreement that this at least needs to be documented far better.
Personally, I think it is generally good to have issues fixed. And the download itself is fairly small. Since these fixes target OCW only, it is good in case you have a GI home since issues known to be open in the GI part in the database home get fixed. In this particular case you are advised to install the GI RU 19.17.0 into your DB home anyway as you can see in MOS Note: 555.1.
And for customers with no GI portion anywhere, you may simply not care since none of the fixes delivered with this merge will bother you. The important fact is that other issues were fixed in the MRP3 including security fixes (always named “Fix for bug …”). That is the important part. No harm is done to the home.
I just would have wished we would have be more clear in the MOS notes and the README of the patch about it to avoid surprises.
The fact that the MRP gets delivered as a system patch is not helpful. At first it requires opatchauto, next it blocks the patch selection with opatch -napply.
Further Links and Information
- MRP3 for Oracle 19.17.0 on Linux – Patch 34935010
- README of MRP3 for 19.17.0
- MOS Note: 888.1 – Primiary Note for Database Proactive Patching Program
- Applying MRP2 from December 2022 for 19.17.0
- Applying the first MRP
- Patching News: RURs are gone – long live MRPs
- MOS Note: 2898381.1 – Sunsetting of 19c RURs and FAQ
- MOS Note: 2898740.1 – Introducing Monthly Recommended Patches (MRPs) and FAQ
–Mike
Hello, Mike,
Wery informative and interesting analysis.Thank you!
Continue, please, a comparison table of one-off patches included in each MRP (this table took place in your article about MRP2 after words “So let me bring the above list into an side-by-side order to allow comparison…” )
Hi Yury,
I will do this for MRP4 again – thanks for asking 🙂
Cheers,
MIke
Hi Mike,
Now with (GI/DB)MRP19.18 things became even worse. A new provision with “runInstaller -applyRU-applyOneOffs” fails with DBMRP, but works with GIMRP. Their respective READMEs clearly show that, DBMRP goes with napply, GIMRP goes with opatchauto.
Regards, Nariman
Hi Nariman,
we heavily criticized this already. But as of now, some people think that are smarter than us (and smarter than our customers). If you are tired of this, please open an SR, and drop me the SR number either via the blog or directly via email to mike.dietrich ……at…. oracle.com
Cheers
Mike
Hi Mike,
I was testing to patch 19.18 and first MRP for 19.18. As you and Daniel always suggested, I use out of place method but when I try to install a new home with 19.18 and MRP, I got “The patch type is invalid in patch location” error for MRP. I am trying to apply MRP as part of -applyOneOffs parameter. my basic command is like:
$ORACLE_HOME/runInstaller -silent -responseFile install/response/FirstInstall.rsp -applyRU $RU_PATCH -applyOneOffs $MRP_PATCH
when I go to MRP patch directory and run “opatch napply” it applies the MRP without any issue. so, can’t we install MRPs during oracle home installation via runInstaller?
thanks.
Hi Mustafa,
thanks for this question. I confess that I haven’t applied the last two MRPs.
I did ask the person in charge and wait for a reply.
Will get back to you as soon as I receive a reply.
Cheers,
Mike
thank you very much Mike. as far as I see, MRPs that are applied via “opatchauto” are also can be applied during installation but MRPs with “opatch napply” cannot be installed.
Hi Mustafa,
I think “napply” works as well. I will test and blog as soon as time allows.
Cheers,
Mike
Dear Mike,
after waiting a few months now I started to implement MRPs as well and I already ran into the first issue right away.
The delivered readme is far from optimal. It does not even mention to run the process as root, but that’s only a documentation issue.
I tried to install MRP 19.19.230516 (35333960) with a HAS setup and it seems this is not supported. Will it only work on full RAC setup (the readme says so)? Is this by mistake then or intended?
Thanks a lot and best regards,
Matthias.