Yesterday I installed the October cpu patch on one of our client’s system.
Now, I don’t have much experience with cpu patches, but it looked simple enough. Just download the latest version of opatch, adjust the path settings and then use the napply command to apply the patch:
[oracle@xxxxxxxxxx:/data/software/oracle/cpu/OCT2007/6394981]$ opatch napply -skip_subset -skip_duplicate Invoking OPatch 10.2.0.3.3 Oracle interim Patch Installer version 10.2.0.3.3 Copyright (c) 2007, Oracle Corporation. All rights reserved.. Setting N-Apply implicit patch base-directory to /data/software/oracle/cpu/OCT2007/6394981 UTIL session Oracle Home : /opt/oracle/product/10.2.0/db_1 Central Inventory : /opt/oracle/oraInventory from : /var/opt/oracle/oraInst.loc OPatch version : 10.2.0.3.3 OUI version : 10.2.0.3.0 OUI location : /opt/oracle/product/10.2.0/db_1/oui Log file location : /opt/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2007-11-23_11-05-24AM.log Unable to lock Central Inventory. OPatch will attempt to re-lock. Do you want to proceed? [y|n] y User Responded with: Y OPatch will sleep for few seconds, before re-trying to get the lock...
At this point opatch hung, unable to lock the inventory.
After some searching, I found that the locks directory in the oraInventory directory was not owned by oracle but oraclecl:
[oracle@xxxxxxxxxx:/opt/oracle/oraInventory]$ ls -l total 30 drwxrwx--- 2 oracle oinstall 512 Nov 14 17:09 Contents drwxrwx--- 2 oracle oinstall 512 Nov 11 20:25 ContentsXML -rwxrwx--- 1 oracle oinstall 38 Nov 14 18:05 install.platform drwxr-xr-x 2 oraclecl oinstall 512 Nov 14 18:11 locks drwxrwx--- 3 oracle oinstall 1536 Nov 23 11:11 logs -rwxrwx--- 1 oracle oinstall 59 Nov 11 20:25 oraInst.loc -rwxrwx--- 1 oracle oinstall 299 Nov 14 18:02 oraInstaller.properties -rwxrwx--- 1 oracle oinstall 1265 Nov 11 20:25 orainstRoot.sh drwxrwx--- 2 oracle oinstall 512 Nov 11 20:14 oui -rwxrwx--- 1 oracle oinstall 3336 Nov 14 18:02 sessionContext.ser [oracle@xxxxxxxxxx:/opt/oracle/oraInventory]$ cd locks [oracle@xxxxxxxxxx:/opt/oracle/oraInventory/locks]$ ls -l total 0 -rw-r--r-- 1 oraclecl oinstall 0 Nov 14 18:11 writer.lock
Now, this oraclecl user was used to install an oracle client (the system is a test system, where different parts of the application are installed on the same server), and used the same oracle_base and inventory location as the oracle database itself.
I fixed the problem and ran the opatch again.
Only to fail again, this time with the message that several make files could not be found….
At this time I was very happy that this was not a production system :)
Fortunately a quick look on the known issues part in the patch readme showed that the problem occured because the advanced security option was not installed in this oracle home and that it could be fixed by removing the 6397929 directory from the patch directory.
And sure enough, after deleting the directory I managed to install the patch without further problems.
Of course, why a cpu patch fails when a separate licensed option is not installed is an entirely different question.
Installing a cpu patch, easy enough, no?
Sounds familar :-)
Comment by prodlife — 24 November 2007 @ 20:42 |
Try Doc ID: Note:73123.1
I just removed the lock file.
Comment by Dion — 9 April 2008 @ 16:49 |
Dion,
The problem I had was that the oracle user was no longer capable of writing the lockfile to the locks directory, not the lockfile itself.
Comment by dhoogfr — 9 April 2008 @ 18:06 |
helpful information
Thanks,
Comment by Abdulmateen — 21 November 2008 @ 15:14 |