OPatch and Oracle inventory related issues
Oracle Inventory
This document will help you use and troubleshot OPatch and Oracle inventory related errors.
The file /var/opt/oracle/oraInst.loc points to the location of oracle inventory file.
For multiple SID installation, keep one inventory per SID by inserting a new location
into /var/opt/oracle/oraInst.loc and commenting out non related entries before each installation or patching, and pointing oraInst.loc to the Oracle location where you will be doing the install or upgrade.
For example point inventory_loc to a new location on a new Oracle database or new Oracle financials install.
When cloning Oracle Apps point inventory_loc to the source during the preclone steps (adpreclone.pl ) and to the target during the cloning steps of target (adcfgclone.pl).
Sample:
inventory_loc=/u01/app/oracle/oraInventory
Disclaimer: Apply to a TEST environment first. Use on production systems is at DBAs own risk.
Before starting each new installation, make sure that the following file points to a new or the appropriate OraInventory location.:
/var/opt/oracle/oraInst.loc
Very Important:
If it is a new install then point it to a new empty location such as
inventory_loc=/u07/app/oracle/TEST/oraInventory otherwise it would overwrite your current inventory.
opatch
opatch is used to apply database patches.
opatch lsinventory lists all products installed and their corresponding version.
If opatch is not already a part of your database install usually located at $ORACLE_HOME/OPatch then you need to download it from Oracle Metalink following instructions in Note:274526.1; down load the zip file (e.g: p2617419_210_GENERIC.zip or read Metalink note Note:274526.1) and unzip it in your current ORACLE_HOME, it would create a OPatch directory, include the path to this OPatch directory into your $PATH.
Also make sure that inventory_loc in file /var/opt/oracle/oraInst.loc is pointing to the ORACLE_HOME you are going to patch.
Sample run:
opatch lsinventory > opatch_inv.out
Then view opatch_inv.out for a list of all products installed and versions.
To download the opatch from metalink:
- Click on the Patches button
- Click on the “New Metalink Patch Search ”
- If you are not on the “Simple Search” screen, click on the
“Simple Search” button
- Select “Search by” = Patch number, enter the patch number 2617419
and hit “Go”
- Select the correct platform and then download
Following is a sample run of opatch:
Applying database patch 3531936 performance patch using Opatch, which is a rollup patch to correct issues with the Gather Schema Statistics algorithm making the behavior of the Cost Based Optimizer(CBO) more consistent. Metalink Note:135266.1 is recommending to apply this patch as part of the year end phase III.
a) make sure /var/opt/oracle/oraInst.loc is pointing to the instance being patched.
b) shutdown the database instance.
c) Staging area: cd /u14/stage/patches/applied/3531936/3616603
d) Ensure that the directory containing the opatch script appears in your $PATH
% export PATH=$PATH:$ORACLE_HOME/OPatch
e) test opatch is set up properly:
% opatch lsinventory
If the Oracle inventory is not setup correctly this utility will
# fail.
f) If “opatch lsinventory “ worked without error, then enter the following command:
cd /u14/stage/patches/applied/3531936/3616603
opatch apply
g) After installing the patch, the below steps must be run for the patch
# application to be complete:
# connect / as sysdba
# @?/rdbms/admin/prvtstas.plb
# @?/rdbms/admin/prvtstat.plb
Note: If you need to de-install this patch refer to the end of read me of patch 3616603 for instructions.
patches.sh which is for Oracle apps.
You can download this from Metalink and run it as the database owner to list running patches by modules and what is the latest available patch for each modules.
Troubleshooting opatch:
1) Make sure /var/opt/oracle/oraInst.loc is pointing to the instance being patched.
2) Make sure opatch is in your PATH:
export PATH=$PATH:$ORACLE_HOME/OPatch
3) If “opatch lsinventory “ still fails after step 1 and 2 of troubleshooting, giving you java errors, then make sure you have the latest opatch on your system. If you are unsure which patch number to use to get the latest opatch, then open a TAR.
FTP the opatch file into the ORACLE_HOME such as 9.2.0.4 or 10.2 and:
unzip p2617419_10102_GENERIC.zip
Then test opatch:
logon as the database owner (oratest or oraprod)
% export PATH=$PATH:$ORACLE_HOME/OPatch
% opatch lsinventory
4) Once “opatch lsinventory “ runs successfully, then make sure db is down before you run “ opatch apply “.
5) If “opatch lsinventory “ still does not work and if “ opatch apply “ also does not work and you get a “OPatch Exception “ error, then try the following:
Inventory Error is: OPatch Exception:
OUI found no such ORACLE_HOME set in the environment
Can not get details for given Oracle Home
–> Fix is: I researched this on Metalink and here is the solution:
Remove non existent HOME from inventory.xml: sample path for TRAIN: /u14/app/traindb/oraInventory/ContentsXML/inventory.xml
Initially on Server A my inventory.xml looked like this:
<HOME_LIST>
<HOME NAME=”APPSIAS_PROD” LOC=”/u01/app/R11i/prodora/iAS” TYPE=”O” IDX=”2″/>
<HOME NAME=”APPSDB_PROD” LOC=”/u02/app/proddb/9.2.0″ TYPE=”O” IDX=”1″/>
<HOME NAME=”APPSDB_TEST” LOC=”/u11/app/testdb/9.2.0″ TYPE=”O” IDX=”3″/>
<HOME NAME=”APPSIAS_TEST” LOC=”/u08/app/R11i/testora/iAS” TYPE=”O” IDX=”4″/>
<HOME NAME=”APPSIAS_DEVEL” LOC=”/u12/app/R11i/develora/iAS” TYPE=”O” IDX=”5″/>
<HOME NAME=”APPSIAS_TRAIN” LOC=”/u06/app/R11i/trainora/iAS” TYPE=”O” IDX=”6″/>
</HOME_LIST>
And it should rather look like the following because I only have TRAIN on Server A, so removed entries for TEST and PROD:
<HOME_LIST>
<HOME NAME=”APPSIAS_TRAIN” LOC=”/u06/app/R11i/trainora/iAS” TYPE=”O” IDX=”1“/>
<HOME NAME=”APPSDB_TRAIN” LOC=”/u14/app/traindb/9.2.0″ TYPE=”O” IDX=”2“/>
</HOME_LIST>
The reason I have these non-existing homes is that I did have clone instances of PROD TEST and DEVEL on that server and inventory was updated by the rapidclone, now that I no longer have these instance on this server, it is safe to remove them from inventory. Also make sure that /u14/app/traindb/9.2.0/oui/oraparam.ini is pointing to
JRE_LOCATION=/u14/app/traindb/9.2.0/oui/jre/1.3.1
patches.sh which is for Oracle apps.
You can download this from Metalink and run it as the database owner to list running patches by modules and what is the latest available patch for each modules.
Creating the Central Inventory
Oracle Universal Installer enables you to set up the Central Inventory on a clean host
or register an existing Oracle home with the Central Inventory, when it is lost or
corrupted. You can setup the Central Inventory by using the -attachHome flag of
Oracle Universal Installer. The syntax is as follows:
./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME=”<Oracle_Home_Location>” ORACLE_HOME_NAME=”<Oracle_Home_Name>”
CLUSTER_NODES=”<node1,node2>” LOCAL_NODE=”<node_name>”
For a non-Real Application Clusters setup, you need not pass the LOCAL_NODE
variable, and the CLUSTER_NODES variable is empty. The syntax is as follows:
./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME=”<Oracle_Home_Location>” ORACLE_HOME_NAME=”<Oracle_Home_Name>”
CLUSTER_NODES=”{}”
Note: For Oracle Universal Installer version 10.2.0.2.0 and above,
you will have the following scripts in Oracle home to recover from
Oracle home inventory corruption:
? detachHome.bat / detachHome.sh: Use this script if the Oracle
home is corrupted or needs to be updated.
? attachHome.bat / attachHome.sh: Use this script if the Oracle
home needs to be added to the inventory.
About Oracle Installer (OUI ./runInstaller):
Before running Oracle Installer, make sure oracle OS account can run kmtune and swlist:
- /usr/sbin/kmtune is what Oracle installer uses to check OS parameters on HP-UX.
- The OUI uses ’swlist -l bundle’ to look for packages, and ’swlist -l fileset’ to look for patches. ’swlist’ is also in /usr/sbin.
- To skip pre-install checks: ./runInstaller -ignoreSysPrereqs