MRP3 for Oracle 19.17.0 adds an interesting surprise

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.

 

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:

MRP3 for Oracle 19.17.0 adds an interesting surprise

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

–Mike

Share this: