After you apply patches on the binary-level, the next step is to run “data patch” to apply the patches on SQL-level. However, I faced a situation where when running “data patch” an error was raised as shown below with full output:
Interim patch 33808367 (OJVM RELEASE UPDATE: 18.104.22.168.220419 (33808367)):
Binary registry: Installed
SQL registry: Not installed
Current state of release update SQL patches:
22.214.171.124.0 Release_Update 220703022223: Installed
Applied 126.96.36.199.0 Release_Update 220331125408 successfully on 27-MAY-22 01.20.51.384386 AM
Adding patches to installation queue and performing prereq checks…done
The following interim patches will be rolled back:
33561310 (OJVM RELEASE UPDATE: 188.8.131.52.220118 (33561310))
Patch 34133642 (Database Release Update : 184.108.40.206.220719 (34133642)):
Apply from 220.127.116.11.0 Release_Update 220331125408 to 18.104.22.168.0 Release_Update 220703022223
The following interim patches will be applied:
33808367 (OJVM RELEASE UPDATE: 22.214.171.124.220419 (33808367))
Error: prereq checks failed!
patch 33561310: Archived patch directory is empty
Prereq check failed, exiting without installing any patches.
Please refer to MOS Note 1609718.1 and/or the invocation log
for information on how to resolve the above errors.
Why This Happened ?
when you apply JAVA Patch (JVM) the tool will automatically roll-back the previous patch first and then apply the new one, the tool couldn’t find metadata information regarding previous patch for JVM component under sqlpatch directory (it seems it was deleted !) so the error thrown was:
Archived patch directory is empty
so what should you in this case ?
my recommendation is to roll-back the current java patch that is installed on the binary-level (you can check that using $ORACLE_HOME/OPatch/opatch lsinventory command to find the patch id OR using dba_registry_sqlpatch view)
after that run the rollback-command:
$ORACLE_HOME/OPatch/opatch rollback -id xxxxxx
Then, re-apply the “old” JVM patch, and the new JVM together at one shot on the binary level (of course applying the old JVAM patch on the binary level will the create the missing metadata directory under “sqlpatch”) ……after that re-run data patch:
I Hope This Helps !