AutoUpgrade create_home Cannot Apply OCW Patches Delivered Through GI MRPs
While building a new Oracle Home using AutoUpgrade’s create_home functionality, I ran into an interesting limitation involving Oracle Clusterware (OCW) patches delivered as part of a Grid Infrastructure Monthly Recommended Patch (GI MRP) – specifically 19.32 MRP1.
After working with Oracle Support and the AutoUpgrade development team, it turns out this behavior is expected, at least today.
The Scenario
For some times, I’ve successfully used:
patch1.patch=RECOMMENDED,JDK,OCWinside AU’s config file to automatically apply the latest OPATCH, DB RU, OJVM, DPBP, AU, JDK, and OCW patches all at once and it has worked great. However, when August 2026 MRP patches were released, I wanted to create a new OH that included 19.32 RU as well as the 19.32 MRP1, and I assumed the following would also bring in the OCW patch included in the GI MRP:
patch1.patch=RECOMMENDED,JDK,OCW,MRPHowever, that did not happen and it only downloaded and applied the OCW patch that was delivered as part of the 19.32 GI RU, and not the latest one that was packaged with GI MRP. So, I attempted to explicitly specify the GI MRP patch number:
patch1.patch=RECOMMENDED,JDK,OCW,MRP,39834042Using this the download mode worked perfectly, however the create_home operation failed with the following message:
-------------------------------------------------
Errors in database [create_home_1]
Stage [OH_PATCHING]
Operation [STOPPED]
Status [ERROR]
Info [Exception: PATCH111
Err message: AutoUpgradePatchingException [OPatch failed to install /stage/software/database/patches/19000/19.32.1.0.260818/p39834042_1932000DBRU_Linux-x86-64.zip. For details, view the log file located at /u01/app/oracle/cfgtoollogs/autoupgrade/create_home_1/100/opatch/opatch2026-09-03_16-36-19PM_1.log]
oracle.patch.utils.errors.PATCH111:
at oracle.patch.dispatcher.actions.BinaryPatching.runOPatch(BinaryPatching.java:145)
at oracle.patch.dispatcher.actions.BinaryPatching.executePatchStage(BinaryPatching.java:80)
at oracle.patch.dispatcher.def.PatchJobAction.executeStage(PatchJobAction.java:71)
at oracle.commons.dispatcher.JobStage.executeStage(JobStage.java:80)
at oracle.patch.dispatcher.def.PatchJobStage.executeStage(PatchJobStage.java:69)
at oracle.commons.dispatcher.RunJobDefinition.runJob(RunJobDefinition.java:144)
at oracle.patch.dispatcher.def.RunAutoPatchJob.runJob(RunAutoPatchJob.java:61)
at oracle.patch.dispatcher.AutoPatchJobThread.run_(AutoPatchJobThread.java:119)
at oracle.patch.dispatcher.AutoPatchJobThread.run(AutoPatchJobThread.java:108)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
]
-------------------------------------------------
Logs: [/u01/app/oracle/cfgtoollogs/autoupgrade/create_home_1/100/autoupgrade_patching_20260903_user.log]
-------------------------------------------------+----+-------------+-----------+---------+------+----------+-------+----------------------------------------+
|Job#| DB_NAME| STAGE|OPERATION|STATUS|START_TIME|UPDATED| MESSAGE|
+----+-------------+-----------+---------+------+----------+-------+----------------------------------------+
| 100|create_home_1|OH_PATCHING| STOPPED| ERROR| 16:28:29| |AutoUpgradePatchingException [OPatch fai|
+----+-------------+-----------+---------+------+----------+-------+----------------------------------------+
What Happened?
AutoUpgrade treated the GI MRP patch number as a standard patch request and attempted to process it using opatch napply and OPatch immediately rejected it with this message:
This command doesn't support System Patch.
OPatch failed with error code 21The reason seems to be that GI MRPs are delivered as System Patches, and the workflow AutoUpgrade uses for explicitly specified patch numbers cannot process them.
Oracle’s Confirmation
Oracle Support escalated the question to the AutoUpgrade development team, who confirmed that:
- OCW resolves only the OCW patch associated with the Database RU.
- Adding MRP does not cause AutoUpgrade to select the OCW patch contained within a GI MRP.
- There is currently no supported keyword or configuration that tells AutoUpgrade to extract and apply the OCW child patch from a GI MRP.
- Specifying the GI MRP patch number directly is not supported and results in the failure shown above.
In other words, AutoUpgrade understands the OCW keyword, but it does not currently understand: Use the OCW patch bundled in the latest GI MRP if MRP keyword is present in the patch parameter of the config file!
Why This Matters
As Oracle continues delivering more fixes through Monthly Recommended Patches, administrators increasingly expect AutoUpgrade to manage the relationships between:
- Database RUs
- GI RUs
- MRPs
- OCW patches packaged within those MRPs
From a DBA perspective, it feels natural that:
patch1.patch=RECOMMENDED,JDK,OCW,MRPwould result in the most current OCW patch being applied, regardless of whether that patch originated from a GI RU or a GI MRP.
Today, that is not the case.
Final Thoughts
This turned out not to be a configuration issue or a missing patch, but rather a current AutoUpgrade limitation.
At the time of writing:
- OCW applies the OCW patch associated with the RU.
- MRP does not resolve OCW patches contained within GI MRPs.
- GI MRP patch numbers cannot be supplied directly to AutoUpgrade’s patch configuration.
- There is no supported mechanism for AutoUpgrade to apply an OCW patch that exists only as a child patch within a GI MRP.
Hopefully this post saves other DBAs some troubleshooting time. It also seems like a reasonable enhancement opportunity for a future AutoUpgrade release.
Special thanks to Oracle Support, the AutoUpgrade development team, and Mike Dietrich for helping investigate and clarify the current behavior.