Applying the MRP from December 2022 to Oracle 19c

Posted on December 21, 2022 by Patch Recommendation 16

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.

 

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.

Applying the MRP from December 2022 to Oracle 19c

 

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

–Mike

Share this:

Tags:

You may also like...

16 Responses

  1. Jean-Jules Fogang says:
    December 21, 2022 at 17:44

    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?

    Reply
    • Mike.Dietrich says:
      December 22, 2022 at 18:22

      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

      Reply
  2. Marian Bednar says:
    December 29, 2022 at 09:58

    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.

    Reply
    • Mike.Dietrich says:
      January 25, 2023 at 17:55

      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

      Reply
  3. Daniele Fusar Bassini says:
    December 29, 2022 at 14:05

    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

    Reply
    • Mike.Dietrich says:
      January 25, 2023 at 17:56

      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

      Reply
  4. Yeki says:
    January 13, 2023 at 03:57

    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.

    Reply
  5. Christian Floreck says:
    January 17, 2023 at 19:46

    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

    Reply
  6. Thomas May says:
    January 27, 2023 at 11:51

    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

    Reply
    • Mike.Dietrich says:
      January 27, 2023 at 12:16

      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

      Reply
  7. Thomas May says:
    February 1, 2023 at 11:25

    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

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mike Dietrich
Oracle Senior Director of Product Manager for Database Upgrade, Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 7,850 other subscribers

Follow me on Twitter