Fun with OPatch

Since the January 2010 CPU patch came out recently, I began to apply the various pieces to my non-Production environments, as usual, just to ensure the process worked as normal.   OPatch is such a clumsy little tool, though I suppose it’s better than in the past when you had to manually pull about 20 readme’s and work for hours on the command line to apply security patches.  If you’re a glutton for bad memories, check out the application of Security Alert #68 or more specifically the database piece. It does make the current CPUs seem well polished by comparison.  But still, nothing ever goes as planned…

I go to apply PSU January 2010 (aka 10.2.0.4.3) on Linux x86-64 against a 10.2.0.4 database home  and I receive this error:

OPatch: ApplySession failed: Patch ID is null.

SEVERE:OPatch invoked as follows: 'apply '
INFO:
Oracle Home       : /u01/highjump/highjumpdb/10.2.0
Central Inventory : /opt/oracle/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.2
OUI version       : 10.2.0.4.0
OUI location      : /u01/highjump/highjumpdb/10.2.0/oui
Log file location : /u01/highjump/highjumpdb/10.2.0/cfgtoollogs/opatch/opatch2010-01-20_09-48-35AM.log

INFO:Starting ApplySession at Wed Jan 20 09:48:36 EST 2010
INFO:Starting Apply Session at Wed Jan 20 09:48:36 EST 2010
SEVERE:OUI-67073:ApplySession failed: Patch ID is null.
INFO:System intact, OPatch will not attempt to restore the system
INFO:Finishing ApplySession at Wed Jan 20 09:48:36 EST 2010
INFO:Total time spent waiting for user-input is 0 seconds.  Finish at Wed Jan 20 09:48:36 EST 2010
INFO:Stack Description: java.lang.RuntimeException: Patch ID is null.
INFO:StackTrace: oracle.opatch.PatchObject.getPatchID(PatchObject.java:543)
INFO:StackTrace: oracle.opatch.ApplySession.loadAndInitPatchObject(ApplySession.java:1485)
INFO:StackTrace: oracle.opatch.ApplySession.process(ApplySession.java:5189)
INFO:StackTrace: oracle.opatch.OPatchSession.main(OPatchSession.java:1588)
INFO:StackTrace: oracle.opatch.OPatch.main(OPatch.java:619)

Super.  What a nice, descriptive error.  A little hunting on MOS reveals that my OPatch version in the $ORACLE_HOME isn’t up to date.  Why couldn’t the error message be “Your version of OPatch is too old to support this patchset”??  Well this was remedied easily enough by downloading/upgrading to the latest version of 10.X OPatch.

Now the patch (9119284) progresses far enough to hit   a new issue:

Patch 7580744:
Archive Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/lib/libcore10.a/ldm.o" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot update file '/u01/highjump/highjumpdb/10.2.0/lib/libcore10.a' with '/ldm.o'
Archive Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/lib/libcore10.a/sldigpts.o" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot update file '/u01/highjump/highjumpdb/10.2.0/lib/libcore10.a' with '/sldigpts.o'
Archive Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/lib32/libcore10.a/ldm.o" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot update file '/u01/highjump/highjumpdb/10.2.0/lib32/libcore10.a' with '/ldm.o'
Archive Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/lib32/libcore10.a/sldigpts.o" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot update file '/u01/highjump/highjumpdb/10.2.0/lib32/libcore10.a' with '/sldigpts.o'
Copy Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/oracore/zoneinfo/timezone.dat" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot copy file from 'timezone.dat' to '/u01/highjump/highjumpdb/10.2.0/oracore/zoneinfo/timezone.dat'
Copy Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/oracore/zoneinfo/timezlrg.dat" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot copy file from 'timezlrg.dat' to '/u01/highjump/highjumpdb/10.2.0/oracore/zoneinfo/timezlrg.dat'
Copy Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/oracore/zoneinfo/readme.txt" does not exist.
'oracle.oracore.rsf, 10.2.0.4.0': Cannot copy file from 'readme.txt' to '/u01/highjump/highjumpdb/10.2.0/oracore/zoneinfo/readme.txt'
Archive Action: Source file "/u01/highjump/highjumpdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23/files/lib/libserver10.a/prm.o" does not exist.
'oracle.rdbms, 10.2.0.4.0': Cannot update file '/u01/highjump/highjumpdb/10.2.0/lib/libserver10.a' with '/prm.o'

DST10

Prerequisite check "CheckRollbackable" on auto-rollback patches failed.

Super.  Now my inventory of Rollbackable (wtf is that a word?) patches is messed up.  I chose option 3 from Doc 751107.1 and just copied the stupid files from another Oracle Home on the server:

$ cd /u01/highjump/highjumpdb/10.2.0/.patch_storage/
$cp -R /u01/labworks/labworksdb/10.2.0/.patch_storage/7580744_Dec_10_2008_23_06_23 .

Finally, OPatch grudgingly applied the PSU patch.  Cranked up the database, ran $OH/rdbms/admin/catbundle.sql psu apply I was done.