A few weeks ago I blogged about the fact that we retired the RURs, and instead release the MRPs (Monthly Recommended Patches). In my previous blog post about this topic you’ll find also an FAQ hopefully answering all the questions you may have (had). And now it is mid of November, so I can show you the process of applying the first MRP for Oracle 19.17.0.

Photo by Glenov Brankovic on Unsplash
How do you get access to the MRPs?
At the moment while I write this, you can find the MRPs only in MOS Note: 888.1 -Primary Note for Database Proactive Patch Program – but a link/section in MOS Note: 555.1 – Oracle Database 19c Important Recommended One-Off Patches should appear soon as well.

MOS Note: 888.1 -Primary Note for Database Proactive Patch Program
.
What is in the MRP1 for Oracle Database 19.17.0?
Speaking about the contents, those 7 fixes are included.
34737974/ ├── 30691454 ├── 33896423 ├── 34333986 ├── 34366627 ├── 34538232 ├── 34574048 ├── 34724125 ├── automation ├── bundle.xml ├── README.html └── README.txt
3 of them are from MOS Note: 555.1, 3 are important additional fixes, and 1 is a security fix for a 3rd party software. But find the description further down below in my blog post under How does the inventory tell you that you’ve applied an MRP?.
How do you apply an MRP?
At first, it is of vital importance that you’ll have the most recent opatch applied, but also that you do the conflict check beforehand as I usually show in my quarterly blog post such as in Patching all my environments with the October 2022 Bundle Patches. As MRPs are nothing different then a few one-off patches bundled together, I thought you should make sure that no conflicting patch is installed already.
Conflict and Space Check
But … surprise surprise … I better should have studied the README before 🙂
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, Oracle Corporation. All rights reserved. PREREQ session 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.33 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-11-16_16-36-53PM_1.log This command doesn't support System Patch. OPatch failed with error code 21
So better read the README.
Conflict check done the right way for this MRP
$ $ORACLE_HOME/OPatch/opatchauto apply -binary . -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-11-16_16-40-23_binary.log Patch selected: /home/oracle/34737974 Analysing this list of patches : [/home/oracle/34737974/33896423, /home/oracle/34737974/34333986, /home/oracle/34737974/30691454, /home/oracle/34737974/34538232, /home/oracle/34737974/34574048, /home/oracle/34737974/34366627, /home/oracle/34737974/34724125] ... Analysis completed. ==Following patches were SUCCESSFULLY analyzed to be applied: Patch: /home/oracle/34737974/33896423 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log Patch: /home/oracle/34737974/34333986 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log Patch: /home/oracle/34737974/30691454 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log Patch: /home/oracle/34737974/34538232 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log Patch: /home/oracle/34737974/34574048 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log Patch: /home/oracle/34737974/34366627 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log Patch: /home/oracle/34737974/34724125 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-16_16-40-24PM_1.log opatchauto SUCCEEDED.
Be prepared that this may take a while depending on the number of patches you have in your home – and I have a number of them. In my playground environment the apply took start-till-end almost 12 minutes which has to do at first with the dependency checks but also the sole patch apply itself took 5 minutes alone.
Do you have to use opatchauto?
It is total news to me that the README does not speak about opatch but instead solely opatchauto. Above you could read already that the prechecks as I used to do them with opatch for space and conflicts fail. But I had to try whether I at least could apply the MRP with opatch.
This is the error I received when I used opatch:
$ $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 12.2.0.1.33 Copyright (c) 2022, Oracle Corporation. All rights reserved. ZOP-51: The patch location is not valid for apply, because it doesn't have correct metadata, or it points to a patch directory. Argument(s) Error... Patch location is not valid for apply Please check the arguments and try again. OPatch failed with error code 135
But I could climb down to every subdirectory, and install each patch separately with opatch. Of course, this is not the idea of a patch bundle. But I wonder why I can install the Data Pump Bundle Patch with opatch – and the new MRP requires opatchauto. Let me check this with our patching authorities – and I will update this blog post once I have more knowledge about it.
So in summary, the answer is (right now): Yes, you will have to use opatchauto at the moment since this is built like a system patch.
Timur asked me whether I tried out opatch napply – but this will fail as well with the This is not a system patch error message.
Do you need to invoke datapatch?
Again, let’s consult the README. Since it would be painful for you to walk through all the patches manually, and in case you haven’t seen this in the README:
- Note: MRP 19.17.0.0.221115 does not include any SQL changes and hence datapatch does not need to be run post installation. This may change for future MRPs.
what would happen if you ran datapatch accidentially?
$ $ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.17.0.0.0 Production on Thu Nov 17 13:20:54 2022 Copyright (c) 2012, 2022, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_21181_2022_11_17_13_20_54/sqlpatch_invocation.log Connecting to database...OK Gathering database info...done Note: Datapatch will only apply or rollback SQL fixes for PDBs that are in an open state, no patches will be applied to closed PDBs. Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation (Doc ID 1585822.1) Bootstrapping registry and package to current versions...done Determining current state...done Current state of interim SQL patches: Interim patch 33192694 (OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)): Binary registry: Not installed PDB CDB$ROOT: Rolled back successfully on 19-JAN-22 10.14.44.327180 PM PDB PDB$SEED: Rolled back successfully on 19-JAN-22 10.14.44.347566 PM Interim patch 33561310 (OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310)): Binary registry: Not installed PDB CDB$ROOT: Rolled back successfully on 20-JUL-22 09.17.02.767339 PM PDB PDB$SEED: Rolled back successfully on 20-JUL-22 09.17.02.812896 PM Interim patch 34086870 (OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870)): Binary registry: Not installed PDB CDB$ROOT: Rolled back successfully on 08-NOV-22 11.05.34.788571 PM PDB PDB$SEED: Rolled back successfully on 08-NOV-22 11.05.36.745638 PM Interim patch 34411846 (OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)): Binary registry: Installed PDB CDB$ROOT: Applied successfully on 08-NOV-22 11.05.35.742058 PM PDB PDB$SEED: Applied successfully on 08-NOV-22 11.05.37.696607 PM Interim patch 34734035 (MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187): Binary registry: Installed PDB CDB$ROOT: Applied successfully on 08-NOV-22 11.05.36.721787 PM PDB PDB$SEED: Applied successfully on 08-NOV-22 11.05.38.671338 PM Current state of release update SQL patches: Binary registry: 19.17.0.0.0 Release_Update 220924224051: Installed PDB CDB$ROOT: Applied 19.17.0.0.0 Release_Update 220924224051 successfully on 08-NOV-22 11.05.35.738500 PM PDB PDB$SEED: Applied 19.17.0.0.0 Release_Update 220924224051 successfully on 08-NOV-22 11.05.37.692881 PM Adding patches to installation queue and performing prereq checks...done Installation queue: For the following PDBs: CDB$ROOT PDB$SEED No interim patches need to be rolled back No release update patches need to be installed No interim patches need to be applied SQL Patching tool complete on Thu Nov 17 13:21:25 2022
No worries. Nothing happens since datapatch detects that nothing needs to be done.
How does the inventory tell you that you’ve applied an MRP?
This is actually a little bit disappointing. You will see it below:
$ $ORACLE_HOME/OPatch/opatch lsinventory | grep -i "Patch Description" Patch description: "Fix for bug 34724125" Patch description: "POD EEHO-DEV5 UNABLE TO SWITCHOVER ODS DB" Patch description: "AFTER GI PATCHING AND DB UPGRADE TO 19.16 SESSIONS ARE CONSUMING TEMPTABLESPACE." Patch description: "DNFS IO HANG DURING STRESS TEST" Patch description: "AIM ORA-600 [KTUSCV1 CV BUF TOO BIG] - KTUSCV1" Patch description: "FLUSH OUT STALE ANTILOCKS AND CONVERT KCLCLS_2 AND KCLANTILOCK_17 TO SOFT ASSERT" Patch description: "SYD E1POD DBHOME PATCHING COMPLETELY HUNG WITH KPDBHASHTABLE_FIND MULTIPLE INSTANCE HANG" Patch description: "MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187" Patch description: "OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)" Patch description: "Database Release Update : 19.17.0.0.221018 (34419443)" Patch description: "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"
At the moment you’ll have no indication that an MRP has been applied. The MERGE patch you see in my list above is the 19.17.0 Data Pump Bundle Patch, not the MRP1 for 19.17.0. There you’ll find the first 7 fixes as the one-offs the MRP applied. This will make it hard to maintain MRPs in my humble opinion. But let us see what we can improve here.
Quick addition since I’ve been asked:
If you wonder what “Fix for bug 34724125” stands for, at first you won’t be able to find anything in the searchable bugs in MOS, and second, the reason is that every fix labeled only with “Fix for bug …” is most likely a security fix.
Can you rollback the MRP easily?
Of course I’ve had to try the rollback as well. But I hit another surprise. Every patch got rolled back one-after-another separately. I guess that opatch checks my inventory for every patch it rolls back over and over again. So for 7 patches to rollback, it takes 6 minutes for each of them. Now you guessed it already, the rollback of the MRP in my environment took over 40 minutes.
$ $ORACLE_HOME/OPatch/opatchauto rollback -binary . -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-11-17_10-56-30_binary.log Target type : oracle_database Patch selected: /home/oracle/34737974 Analysing this list of patches : [/home/oracle/34737974/33896423, /home/oracle/34737974/34333986, /home/oracle/34737974/30691454, /home/oracle/34737974/34538232, /home/oracle/34737974/34574048, /home/oracle/34737974/34366627, /home/oracle/34737974/34724125] ... Analysis completed. Rolling back the patches ... Patches successfully rolled back. ==Following patches were SUCCESSFULLY rolled back: Patch: /home/oracle/34737974/33896423 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log Patch: /home/oracle/34737974/34333986 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log Patch: /home/oracle/34737974/30691454 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log Patch: /home/oracle/34737974/34538232 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log Patch: /home/oracle/34737974/34574048 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log Patch: /home/oracle/34737974/34366627 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log Patch: /home/oracle/34737974/34724125 Log: /u01/app/oracle/product/19/cfgtoollogs/opatchauto/core/opatch/opatch2022-11-17_10-56-31AM_1.log opatchauto SUCCEEDED.
My inventory looks fine afterwards.
$ $ORACLE_HOME/OPatch/opatch lsinventory | grep -i "Patch Description" Patch description: "MERGE ON DATABASE RU 19.17.0.0.0 OF 34650250 34660465 24338134 25143018 26565187" Patch description: "OJVM RELEASE UPDATE: 19.17.0.0.221018 (34411846)" Patch description: "Database Release Update : 19.17.0.0.221018 (34419443)" Patch description: "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"
So in summary, the rollback works fine but takes quite a bit since each patch gets rolled back separately – and I guess the inventory check happens over and over again:
2022-11-17 11:30:32,257 INFO [1] oracle.glcm.opatch.common.impl.SingletonPatch - /u01/app/oracle/product/19/inventory/oneoffs/34574048/etc/config/maintenance_alias.xml does not exist 2022-11-17 11:30:48,148 FINE [1] oracle.opatch.util.perfmonitor.MethodTrackerObj - Error while ending the tracker. Message - null 2022-11-17 11:37:11,046 INFO [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Singleton patch is found 2022-11-17 11:37:11,046 INFO [1] oracle.glcm.opatch.common.impl.PatchFactoryImpl - Patch type found: SINGLETON_PATCH
taking a full 6 minutes in my environment for every patch. We’ll investigate this further.
But keep in mind that rolling back an RU will require that you’d rollback the MRP at first. Otherwise this will happen to you:
Patches will be rolled back in the following order: 34419443 Prerequisite check "CheckPatchRollbackDependents" failed. The details are: OPatch will not roll back patch(es) "34419443" until you have rolled back dependent patch(es) "34734035,30691454,33896423,34333986,34366627,34538232,34574048,34724125".
So I need to rollback the 7 one-offs at first before I can rollback the RU. Doesn’t make life easier to be frank. And please scroll up a little but to see how to rollback the MRP one-offs with opatchauto in one pass.
.
Summary after applying the first MRP
I expected a lot. And I see some room for improvement. Certainly we sent feedback to the group owning the process to build the MRPs. So let us see what we can get, and in mid December I will blog again about MRPs as soon as MRP2 for 19.17.0 will be available.
When you take the fact that I’ve had to download the 7 fixes delivered with the MRP manually by myself, apply them etc – then the MRP is a conveniently easing this procedure for me. But I can sense that you’d like to have the ability to use opatch instead of opatchauto, and to have a more obvious way to maintain MRPs within the inventory.
So overall, MRPs are a good thing – but not a must-apply – patch bundle. And let us see which improvements we can get for the next one in mid December.
We highly recommend that you provision a new home with ./runInstaller -applyRU … -applyOneOffs … . Daniel tested this successfully yesterday already. He applied not only 19.17.0 but the MRP1, the Data Pump Bundle Patch, the OJVM and the most recent time zone patches all in one command. And this way you don’t have to fiddle around with opatchauto and the long-running rollback. And you don’t carry around a full-blown patch inventory which makes every patch apply taking longer and longer.
Further Information and Links
- Bye bye RURs – Long live MRPs
- FAQ about 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
–Mike
Hi Mike
Thanks for you usual great article
I don’t think this would be a good idea to patch our databases monthly… RUs quarterly was the prefect patching method so far.
This monthly patching will confuse us 🙂
Thanks
Hi Mustafa,
as we said multiple time, it is really meant for convenience – and you should always have an eye on 555.1. But there is no “must-apply” thing for MRPs.
Cheers
Mike
Hi Mike,
This MPR conflict with the patch 34649727 from 555.1:
Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
34366627, 34649727
“Conflict checker” tool also confirms the conflict – but proposes no merge patch 🙂
Regards, Nariman
Thanks Nariman,
somebody internally sent a description of the same issue an hour ago to the RAC mailing list. I will keep an eye on it and update the blog post as soon as I have more details. But thanks (and sorry for the inconvenience).
Cheers,
Mike
Hi Mike,
The most recent OPatch is 12.2.0.1.34 released on Nov 14th 🙂
Not sure if it would make a difference but I´m wondering a bit that there is another OPatch release just one month after 12.2.0.1.33.
Thanks Andreas – I did not know what enhancements have been done. But I will ask the release manager.
Cheers
Mike
Hi Andreas,
the reason for the recut is the addition of a fix for CVE-2022-42004 & CVE-2022-42003 (Jackson).
Cheers, and thanks for the pointer!
Mike
Might be worth noting that MRP’s are only applicable to Linux platforms per Note 888.1; all other platforms going forward (after the 19.16.2 RUR coming in January 2023) only receive the quarterly RU and should consult Note 555.1 for recommended patches that may be applicable to their environment. Hopefully MRP’s will be expanded to other platforms in the future, perhaps with some of the improvements noted in your post?
Hi Richard,
I did mention this already:
https://mikedietrichde.com/2022/10/26/patching-news-rurs-are-gone-long-live-mrps/
Cheers
Mike
Sorry, I missed that part earlier.
No worries – there are too many blog posts. And I certainly recognized the fact that RURs were available on SPARC, AIX etc – but MRPs aren’t right now.
I personally hope that we’ll get “Gold Images as a Service” finally soon – but until then you may unfortunately live with no MRPs on SPARC, AIX etc.
My guess is that the powers will wait for the download numbers. If MRPs become really popular – and some of the starting issues get resolved, then they may come as well on the other ports.
Cheers
Mike
I was encouraged by the inclusion of 34366627 as we currently have that installed as a one-off patch, so that requirement should go away with the next quarterly patch as all of these patches should be included in it.
I’d hope so, Lance!
Cheers
Mike
Hi Mike,
How can we run the conflict check before installing. I want to use runInstall with -applyRU and -applyOneOffs where the oneoffs include the MRP, OJVM, DPBP and the other patches listed in 555.1 for 19.17.0.
I too hit the conflict between 34366627 and 34649727.
But how could I have tested for this with only 19.3.0 unzipped and nothing yet runInstalled-ed?
Anthony
Hi Anthony,
I think you need to pass on all the patch numbers you’d like to apply in one pass into the patch conflict checker:
Oracle Support Document 1091294.1 (How to Use the My Oracle Support Conflict Checker Tool for Patches Installed with OPatch.) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=1091294.1
Then it will tell you about potential conflicts. And the issue with 34366627 and 34649727 gets solved – I am surprised as well that this could slip through 🙁
Cheers
Mike
Hello, Mike
You recommend to create new OH. For example: i have database with name “orcl” working from OH 19.16. I successfully installed new OH 19.17 and my db orcl work from OH 19.17 now.
All works well. So i decided to deinstall OH 19.16.
I run ./deinstall from 19.16 home and it try to remove my database orcl !
#### DECONFIG CHECK OPERATION SUMMARY ####
Oracle Home selected for deinstall is: /u01/app/oracle/19.16
Inventory Location where the Oracle home registered is: /u01/app/oraInventory
The following databases were selected for de-configuration. The databases will be deleted and will not be useful upon de-configuration : orcl
Database unique name : orcl
Storage used :
Do you want to continue (y – yes, n – no)? [n]: n
Exited from program.
### ORACLE DECONFIG TOOL END ###
How to deinstall old unnesseccary OH and don’t touch the DB ?
Thank you !
Hi Yu,
please see here – and test it carefully. I haven’t played a lot with the 19c deinstallation yet.
https://mikedietrichde.com/2018/06/19/deinstalling-oracle-database-12-2-0-1/
Cheers,
Mike
good afternoon mike,
your blog pointed out an important thing for me. using opatchauto instead of the usual opatch.
that’s one thing, and i am not happy wiht that :-(.
i usually do a opatch analyze uising oracle support before downloading and installing.
so i did this also before downloading patch 34737974 ( the first MRP for NOV 2022).
it indicated in my case a conflict for bug fix 34538232.
but i am wondering now, is this analyze being done the way you described?
Hi Kees,
it could be that BUG 34538232 – AFTER GI PATCHING AND DB UPGRADE TO 19.16 SESSIONS ARE CONSUMING TEMPTABLESPACE conflicts with the MRP. If a conflict got flagged, you may need to open an SR and request a merge of the MRP with the fix for 34538232.
I did the conflict check as described in the README. There is another option to have a check run in the “patch” screen on MOS as well.
Cheers,
Mike
Hi Mike,
befor applying new RUs I have to rollback OnOffs or MRPs then apply new RU and new OnOffs/MRPs.
My question is: can I combine the rollback and apply in one step or should be rollback and apply in separate manner. The best would be something like this scheme
opatch rollback OnOff1 OnOff2 .. apply RU17 NewOnOff1 NewOnOff2 in one step. This would save a lot of time especially in RAC envs.
Thank you
Hi Peter,
I tried in my environment, and at least I’ve had to rollback step-by-step.
Ideally you’d deploy a new home and avoid any rollback of the binary patches.
Cheers
Mike
Hi Mike,
step by step apply the binaries won’t be a problem.
My point is, it is possible to combine in a RAC env.
rollback the OneOffs Binaries with opatch,
apply the RU Binaries with opatchauto,
apply the MRP or new OneOffs Binaries with opatch/opatchauto
without a restart of the instance of opatchauto while applying the RU
After doing this on the first node, same procedure on the last node, at the end with “datapatch” for the OneOff SQL changes (rollbacks old OneOffs, apply new OneOffs).
I’m also not sure, if you have different binaries between the nodes after patching all binaries on the first node, without having applied all the SQL-Changes,
would this end in a possible trouble?
My problem is the need of multiple restarts of the instance while patching with opatchauto.
I’m not sure (.. and of course I will test it) would the “-norestart” option of opatchauto be an advice?
I do my best phrasing this question, hopefully you understand my intention.
And of course, all would be fine, doing this with OOP 🙂
Thank you very much for your support…
Peter
Hi Peter,
I think for this short amount of time, the different binaries wouldn’t be an issue. But the general problem is what you describe: the instance restarts. If I remember correctly, our ACS experts patch such systems with opatch in order to have control.
I never tried -norestart since I have no RAC to test this. Actually, the best would be really to discuss this with Support. There is only one way to discover a situation with a knowledge system gap – and this is when Support recognizes that they have no MOS note explaining this out there.
But I see where this may lead to 🙁
And yes, OOP would be the best answer, especially since you’d avoid the nasty rollback of a patch.
The best recommendation would be FPP (Fleet Patching and Provisioning) since it handles this entirely, and even patches GI OOP. Since you have RAC systems, the license is part of RAC. Have you ever considered this before?
Thanks
Mike
Thank you Mike, FPP I’ve never tested.
We were not sure, if this is part of “provisioning pack”. Also I don’t know if this effort is worth for patching of 6 nodes. But I will test it. Without to know the effort of FPP, currently I would prefer OOP or move it to the cloud.
By the way here is a thread with a similar problem:
https://community.oracle.com/mosc/discussion/4509718/how-to-combine-multiple-patches-into-one-single-opatchauto-session
Thank you very much
Peter
Hi Peter,
yes, you have the FPP license automatically when you have RAC licenses. I think we added this automatically maybe 6 or 7 years ago. Before it was a separate license.
If you don’t mind I would like to connect you with Philippe Fierens. He is our PM for FPP and knows everything about RAC first hand since he worked 2 decades in the field with/at large customers. He’s based in Belgium – but when his time allows, he could give you a quick 60 min overview on FPP and how to set it up easily.
The idea then is that you prepare your Gold Image with all the patches you want, and let FPP deploy it to your target systems – and then of course do the patching, the switching of homes etc etc. Even for 6 RAC clusters it could ease your work a lot, and it doesn’t cost anything extra. FPP does some really smart things.
Please drop me a message via email, and I will connect you with Philippe directly.
Cheers,
Mike
Hi Mike,
the README.html contains in the line
$ORACLE_HOME/OPatch/opatchauto apply -binary /34737974 -analyze -online
a nbsp; instead of a normal space before -analyze.
So copying the line and replacing
with the correct path leads to the error: OPATCHAUTO-72080: Invalid patch location.
Perhaps you could notify someone of that problem, otherwise it’s possible that it sticks around with the next MRPs.
Tnx for the great post!
Regards,
Christof
Thanks Christof – I will alert the owners of the README.
Cheers
Mike
Hi Mike,
This is great information as usual. I have a question about this statement above “We highly recommend that you provision a new home with ./runInstaller -applyRU … -applyOneOffs” We currently have 19.13 + one-offs installed. We are deploying 119.3 + 9.17 RU + Jan MRP + one-offs using this method. what would the process be if for some reason we need to rollback to the old 19.13 home?
Hi Gilson,
as far as I see from other commenters, the MRPs can’t be applied this way, at least not for the database yet.
I am investigating this right now.
In the above example, it is key that you exchange the opatch version after unpacking 19.3.0 base release. If you don’t do this, it will fail for sure.
1. Unzip 19.3.0 into your future home
2. Remove ../OPatch
3. Unzip opatch into this directory => it will create a new ../OPatch directory
4. Have a separate directory with subdirs such as I explained here: https://mikedietrichde.com/2022/05/17/simple-database-installation-with-applyru-and-applyoneoffs/
For the MRP, please be patient – I will blog something about it as soon as I have more clarity.
Cheers
Mike
Thank you Mike,
Can you please comment on what the rollback procedure from 19.17 to 19.13 would look like when provisioning a new home for 19.17?
Hi Gilson,
there is no rollback needed when you provision a new home.
In case the MRP has a SQL/PLSQL component, datapatch will rollback everything once called.
Cheers,
Mike