Well, couldn’t there be a nicer pre-Christmas present than the December 2022 Monthly Recommended Patches (MRP)? You know, I’m just kidding. But since I received the first questions from customers – and before I send an email internally – I wanted to try out Applying the MRP from December 2022 to Oracle 19c.

Photo by Kate Ibragimova on Unsplash
Download the December MRP
Actually you need to access MOS Note: 888.1 -Primary Note for Database Proactive Patch Program since the link is not in MOS Note: 555.1 – Oracle Database 19c Important Recommended One-Off Patches even though it lists the fixes included in MRPs.
Just don’t click in 4.3 Monthly Recommended Patches (MRPs) in MOS Note: 888.1. Instead, please click on 6.2 Oracle Database 19c. This will bring you to the download while 4.3 is only a general line about MRPs.
README and Apply Process
Of course you should check the README at first before applying the patch.
Then you will see that it again (or still) requires opatchauto instead of plain opatch. The process to apply the MRP2 is the same as it was in November when I went through Applying the first MRP to my Oracle 19c environments.
At the end of the README you will find a list of included fixes for each MRP:
MRP version | Bug Fixes |
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 |
Since this is a consecutive list, it is very hard to digest and compare. And I already received the first question by Martin Decker whether the MRPs are really cumulative or not – he has his doubts on that.
Plus – now I add a screenshot – did you spot the bracket after MLR 34789241? No. I didn’t either at first sight since somebody did not include a line break or at least a space.
This means that MRP2 will apply:
- MLR 34789241 which contains
- 34060122
- 33896423
- 34310304
- 34377917
- 34485380
- 34562023
- 34715072
- 34545238
- 32295794
Are MRP1 and MRP2 cumulative?
So let me bring the above list into an side-by-side order to allow comparison.
Bug | MRP1 | MRP2 |
30691454 | X | |
32295794 | X | |
33896423 | X | X |
34060122 | X | |
34310304 | X | |
34333986 | X | |
34366627 | X | |
34377917 | X | |
34485380 | X | |
34538232 | X | |
34545238 | X | |
34562023 | X | |
34574048 | X | |
34715072 | X | |
34724125 | X | |
34789241 | X |
I guess this was the reason for Martin’s question. As you can see above, only 1 single fix is part of both MRPs in the bug listing, 33896423 (FLUSH OUT STALE ANTILOCKS AND CONVERT KCLCLS_2 AND KCLANTILOCK_17 TO SOFT ASSERT).
And the last one in the list, 34789241, is the MLR containing 6 one-off fixes.
Wasn’t it the promise that MRPs are cumulative?
This is incredibly hard to find out with the above numbering schema, even when you know patching inside-out.
I started consulting at first MOS Note: 555.1. There it says that several fixes got replaced.
- 34545238 (replaces 34053514)
- 34719373 (replaces 34649727)
But the 2nd one has a tag saying “Not applicable”. Hence, I don’t need to care.
And the first one under its old number 34053514 was not part of MRP1, and therefore does not matter either. Still, the headline of paragraph 5 of the README says:
The following bugs are fixed by this cumulative patch, including bugs from the previous 19.17 MRPs:
So the explanation is in the list above. The MRP2 delivers a Merge Label Request (MLR – a merge patch) containing 6 one-off patches plus 3 additional one-off patches.
Please don’t ask me why they haven’t been included into one single MLR. I can’t tell you.
Do you have to deinstall the previous MRP?
Since my inventory looks like this, I was curious whether I need to deinstall anything before I can apply the new MRP2.
$ $OH19/OPatch/opatch lspatches 34724125;Fix for bug 34724125 34574048;POD EEHO-DEV5 UNABLE TO SWITCHOVER ODS DB 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 33896423;FLUSH OUT STALE ANTILOCKS AND CONVERT KCLCLS_2 AND KCLANTILOCK_17 TO SOFT ASSERT 30691454;SYD E1POD DBHOME PATCHING COMPLETELY HUNG WITH KPDBHASHTABLE_FIND MULTIPLE INSTANCE HANG 34734035;MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187 34411846;OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846) 34419443;Database Release Update : 19.17.0.0.221018 (34419443) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
As you could read in my blog post Applying the first MRP from a month ago, the MRP did not show up as a Bundle Patch or MERGE but instead as a list of one-off patches.
I was of course curious if this is still the case.
$ $ORACLE_HOME/OPatch/opatchauto apply -binary ~/MRP/34819700 -analyze -online 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_2022-12-21_15-08-08_binary.log Patch selected: /home/oracle/MRP/34819700 Analysing this list of patches : [/home/oracle/MRP/34819700/34724125, /home/oracle/MRP/34819700/34366627, /home/oracle/MRP/34819700/34574048, /home/oracle/MRP/34819700/34538232, /home/oracle/MRP/34819700/30691454, /home/oracle/MRP/34819700/34333986, /home/oracle/MRP/34819700/34715072, /home/oracle/MRP/34819700/34789241, /home/oracle/MRP/34819700/32295794, /home/oracle/MRP/34819700/34545238] ... Analysis completed. ==Following patches were SKIPPED: Patch: /home/oracle/MRP/34819700/34724125 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Reason: /home/oracle/MRP/34819700/34724125 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34366627 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Reason: /home/oracle/MRP/34819700/34366627 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34574048 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Reason: /home/oracle/MRP/34819700/34574048 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34538232 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Reason: /home/oracle/MRP/34819700/34538232 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/30691454 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Reason: /home/oracle/MRP/34819700/30691454 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34333986 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Reason: /home/oracle/MRP/34819700/34333986 is not required to be applied to oracle home /u01/app/oracle/product/19 ==Following patches were SUCCESSFULLY analyzed to be applied: Patch: /home/oracle/MRP/34819700/34715072 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Patch: /home/oracle/MRP/34819700/34789241 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Patch: /home/oracle/MRP/34819700/32295794 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log Patch: /home/oracle/MRP/34819700/34545238 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-08-10PM_1.log opatchauto SUCCEEDED.
So I read this as if the first 6 fixes from MRP1 still stay, they are included in the MRP2.
What happened to the seventh one, bug 33896423? When you check the list of fixes included in the MLR 34789241, you will find it. Hence, it is not listed above separately. But it stays in the environment and does not get deinstalled.
Finally, it clearly looks to me as if I’d had nothing to deinstall.
Applying the MRP2 from December 2022
Let’s see if this works as intended.
$ $ORACLE_HOME/OPatch/opatchauto apply -binary ~/MRP/34819700 -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_2022-12-21_15-21-30_binary.log Target type : oracle_database Patch selected: /home/oracle/MRP/34819700 Analysing this list of patches : [/home/oracle/MRP/34819700/34724125, /home/oracle/MRP/34819700/34366627, /home/oracle/MRP/34819700/34574048, /home/oracle/MRP/34819700/34538232, /home/oracle/MRP/34819700/30691454, /home/oracle/MRP/34819700/34333986, /home/oracle/MRP/34819700/34715072, /home/oracle/MRP/34819700/34789241, /home/oracle/MRP/34819700/32295794, /home/oracle/MRP/34819700/34545238] ... Analysis completed. Applying the patches ... Patches successfully applied. ==Following patches were SKIPPED: Patch: /home/oracle/MRP/34819700/34724125 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Reason: /home/oracle/MRP/34819700/34724125 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34366627 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Reason: /home/oracle/MRP/34819700/34366627 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34574048 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Reason: /home/oracle/MRP/34819700/34574048 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34538232 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Reason: /home/oracle/MRP/34819700/34538232 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/30691454 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Reason: /home/oracle/MRP/34819700/30691454 is not required to be applied to oracle home /u01/app/oracle/product/19 Patch: /home/oracle/MRP/34819700/34333986 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Reason: /home/oracle/MRP/34819700/34333986 is not required to be applied to oracle home /u01/app/oracle/product/19 ==Following patches were SUCCESSFULLY applied: Patch: /home/oracle/MRP/34819700/32295794 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Patch: /home/oracle/MRP/34819700/34545238 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Patch: /home/oracle/MRP/34819700/34715072 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log Patch: /home/oracle/MRP/34819700/34789241 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-12-21_15-21-31PM_1.log opatchauto SUCCEEDED.
This is basically the same output as during the -analyze run.
Checking the inventory
This is the inventory AFTER patching with the MRP2 while I’ve had the MRP1 in my home already.
$ $OH19/OPatch/opatch lspatches 34789241;MERGE ON DATABASE RU 19.17.0.0.0 OF 34714645 34060122 34715072;Fix for Bug 34715072 34545238;STABLE_E2POD LGWR WAITS FOR EVENT ENQ CF - CONTENTION FOR 532 SECS. KRBM.C 13489 32295794;FIX BUG IN KSIPC STORAGE IPS DISCOVERY 34724125;Fix for bug 34724125 34574048;POD EEHO-DEV5 UNABLE TO SWITCHOVER ODS DB 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 30691454;SYD E1POD DBHOME PATCHING COMPLETELY HUNG WITH KPDBHASHTABLE_FIND MULTIPLE INSTANCE HANG 34734035;MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187 34411846;OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846) 34419443;Database Release Update : 19.17.0.0.221018 (34419443) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
Of course, it makes no sense now to scroll up and down, so I will list the additions to the inventory BEFORE patching with MRP2.
MRP2 adds these fixes to the inventory:
34789241;MERGE ON DATABASE RU 19.17.0.0.0 OF 34714645 34060122 34715072;Fix for Bug 34715072 34545238;STABLE_E2POD LGWR WAITS FOR EVENT ENQ CF - CONTENTION FOR 532 SECS. KRBM.C 13489 32295794;FIX BUG IN KSIPC STORAGE IPS DISCOVERY
And it removes this fix from the inventory:
33896423;FLUSH OUT STALE ANTILOCKS AND CONVERT KCLCLS_2 AND KCLANTILOCK_17 TO SOFT ASSERT
So the fix removed from the inventory is now part of 34789241 => MERGE ON DATABASE RU 19.17.0.0.0 OF 34714645 34060122. It is very disturbing that the MLR’s text display in the inventory lists only 2 patches, and not all six included.
Do you need to run datapatch?
The MRP is RAC-Rolling and Standby-First as the README indicates. And the README tells you as well that there is no need to run datapatch.
Note: MRP 19.17.0.0.221220 does not include any SQL changes and hence datapatch does not need to be run post installation. This may change for future MRPs.
Summary
The MRP2 for Oracle Database 19c in December 2022 delivers 8 new fixes on top of MRP1. One additional fix which was in MRP1 has been included into a newly built MLR.
You don’t need to deinstall anything if you choose to install in-place. No datapatch needs to be run.
And finally, MRPs are cumulative – and they are a convenience we recommend you to use. But you don’t have to install them. Still, if you plan to go live with 19.17.0 over the end-of-the-year period, you may add the MRP2 before going live fixing 15 important issues by applying one single fix on-top.
Further Links and Information
- 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
- MOS Note: 555.1 – Oracle Database 19c Important Recommended One-Off Patches
- MOS Note: 888.1 -Primary Note for Database Proactive Patch Program
- Patching all my environments with the October 2022 Bundle Patches
- Binary Patching is slow because of the inventory
- Simple Database Installation with applyRU and applyOneOffs
- Patch 34819700: December 2022 DATABASE MRP 19.17.0.0.221220
–Mike
Hello Mark,
In our environment, we don’t pay a lot of attention to the MRP, instead we apply the quarterly CPU. Is there any risk to that?
Hi Jean-Jules,
I tried to explain multiple times that MRPs are just for convenience on-top of an RU. There is no must – but you can easily cure the most problematic known issues with just one single download and apply run.
Cheers
Mike
Hi Mike,
Is available anywhere CVSS Risk Matrix for MRP patches similar to standard CPUs?
Because I am planing to install MRP only if there are some important security fixes e.g. for bugfixes with CVSS score 7.0 and above.
Thank you.
Hi Marian,
you can see the fixed issues flagged in the README or in the inventory when it says “fix for bug …” since this maps always to an security issue. But we asked internally whether we can have a mapping list.
Cheers,
Mike
Hello Mike, do you know if MRP2 patches will also be included in DB RU 19.18?
Generally, is it worth saying that MRPs are always included in the next DB RU?
Regards,
Daniele
Hi Daniele,
if possible, yes. We still have to make sure that code freeze dates allow us to include the fixes. But where possible, this will be done.
Cheers
Mike
Hi Mike,
What if you deinstall the MRP1 and then install MRP2, or just a fresh installation from start that skip MRP1 and install MRP2 directly, is the inventory list still same as above? Sorry I have no environment to test at this time.
Hi Yeki,
please see:
https://mikedietrichde.com/2022/10/26/patching-news-rurs-are-gone-long-live-mrps/
Since there are several merges as I explain in the blog post above, you won’t have the exact same inventory, and of course you have more bugs fixed in MRP2.
Cheers
Mike
Hi Mike,
Thanks for your answer. That’s what I have concern about, will it make DBA (or someone else) hard to determine if two or more oracle home have same patch level by comparing the inventory list? For example, even though they are all in MRP3, they may be like below:
19.17 -> MRP1 -> MRP2 -> MRP3
19.17 -> MRP1 -> MRP3
19.17 -> MRP2 -> MRP3
19.17 -> MRP3
Yeki,
you won’t see the items 1-3 in your list. Once you applied MRP3, the inventory will only display MRP3 since the MRPs are cumulative.
Cheers
Mike
Hi Mike
I just found the Patch 34695858
Named: PLACEHOLDER BUG FOR DATABASE SOFTWARE CLONE 19.17
For me it looks like and GoldImage (19.3 plus Patch 19.17) – is this correct?
Can I apply the Patch 34819700 with apply_oneoffs on top of it?
Thanks
Christian
Hi Christian,
feel free to try it out please.
Cheers
Mike
Servus Mike,
Patch 34935010-DATABASE MRP 19.17.0.0.230117 was released at the same time as 19.18, but it can only be applied on 19.17. Isnt it much better to apply 19.18 now as we do usual? How important is the MRP? Are the fixes included in 19.18?
It would mean some additional effort to integrate the MRPs in our patch cycle with about 150 test and productive databases.
Thank you, Thomas
Hi Thomas,
hope all is well, and if you are THE Thomas (ex-Oracle), then I hope you’ll have still enough “mountain time” 🙂
Regarding the MRP, please watch out on Monday. The MRP3 spills in a lot of extra patches we didn’t expect. We have discussions going on since yesterday night.
But to your initial question:
19.18.0 delivers over 700 fixes on top of 19.17.0 while the MRP3 delivers (in theory) only a dozen fixes on top of 19.17.0. Those fixes are mainly sourced from the recommendation in 555.1 and some additional things we know are important.
Making a long story short, when you are happy on 19.17.0, then the MRP is a convenience to add some of the most important fixes to it.
When you have a bunch of additional one-offs on top of 19.17.0 already, then the MRP is no relief to you since you need to request a merge patch anyways. Hence, the MRP is mainly for those customers doing standard things but want the most recent patches without moving forward to the next RU already. And as you may see in my blog post on next Monday, there are some security fixes in the MRP3 as well.
19.18.0 – has 700 fixes on top. I haven’t checked but most of the MRP3 fixes should be in 19.18.0 already included as well.
But it’s too early to say something about 19.18.0 yet. I don’t have enough customer feedback from people who tested it to the bones.
Cheers,
Mike
Hi Mike,
thank you for your detailed reply, I agree and we consider it.
Yes, I am still a lot out in the mountains and hope the same for you!
All the best, Thomas
Danke Dir!
Und viel Spass beim Skifahren und Wandern (je nach Wetterlage) 🙂
Herzliche Gruesse,
Mike