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.
Seems that our friend Arjudba at “Oracle in World” ran into the same OPatch problem. You can find his story at http://bit.ly/b00sdt.
Comment by Bill Long — April 1, 2010 @ 2:28 pm
Nice information and sharing. Thanks for solution.
Comment by Jack Nicholson — April 15, 2010 @ 12:09 am
[…] Fun with OPatch January 2010 2 comments 4 […]
Pingback by 2010 in review « Kevin Kempf's Blog — January 7, 2011 @ 10:41 pm