Guest Author: Nick Quarmby
We see quite a few Service Requests (SRs) where E-Business Suite customers have gotten into difficulty with the Oracle Universal Installer (OUI) Inventory. It's important to note the Oracle Universal Installer Inventory has nothing to do with the Oracle E-Business Suite Inventory product (product code INV).
The Oracle Universal Installer Inventory is a component of the OUI and creates a record of the Oracle homes, products and patches you have installed on a node. Whilst it's not part of the E-Business Suite, as an Applications DBA it's inevitable that sooner or later you will have to look after the Inventory. This article will focus on issues relating to the OUI Inventory specifically within the context of Oracle Applications.
An Overview of the OUI Inventory
The Oracle Universal Installer Inventory comprises three main components:
Central Inventory and Home Inventory are the official names, however, almost everybody talks about the Global and Local Inventory so it's useful to mention this now as the terms are often used interchangeably.
The Pointer File, created or referenced when running the OUI or rapidwiz, is called oraInst.loc and is used to either locate an existing Central Inventory or tell OUI where to create a new Central Inventory. It's a simple text file, stored, by default, in a system directory. In the Microsoft Windows environment it is stored in the registry key \\HKLM\Software\Oracle\INST_LOC.
The Central Inventory records details of Oracle homes installed on a node. A single node might contain one Central Inventory with details of all Oracle homes on that node, or a single node might contain multiple Central Inventories each one containing details of a single Oracle home.
The Home Inventory is specific to, and contained within each Oracle home, and contains details of patches or updates applied to that specific Oracle home.
This article will concentrate on the Central Inventory as, generally speaking, the Home Inventory looks after itself.
Central Inventory Differences Between Apps 11i and R12
In Apps 11i, the default action was to use a single Central Inventory -- that is, one Central Inventory per node -- which recorded all Oracle homes installed on that node. The Central Inventory Pointer File was stored in a system directory to which you had to have write access. This was why during an EBS 11i installation, or when cloning to a new node, you would be prompted to run scripts as the root user before you could complete your installation or clone. If you had multiple 11i installations on a node, these would generally all be recorded in the same Central Inventory.
In Apps R12, things have changed. If rapidwiz is not able to automatically create a Pointer File in the default system directory, it will create multiple Central Inventories and multiple Pointer Files. Instead of prompting to run a script as the root user, a separate Central Inventory and Pointer File will be created in each Oracle home created on the node.
Things have the potential to get complicated when you have multiple Oracle Applications installations on a single node, or where 11i and R12 installations are both installed on the same node. Start cloning to and from this same node and soon you may be forced to pay attention to the Inventory.
How EBS Creates and Updates the OUI Inventory
Here are a couple of typical examples of how the OUI Inventory is configured during an Oracle Applications installation.
Scenario 1: Upgrading Apps 11i to 12 creates multiple Pointer Files and Central Inventories
A typical scenario might be that you have an 11i test environment installed on your node. You plan to upgrade sometime soon and wish to install a simple R12 test environment on the same node.
By default, the operating system user installing R12 will probably not have permission to update the Central Inventory created by the previous 11i installation. In this case, multiple additional Pointer Files and Central Inventories are created within the new R12 Oracle homes. This in itself is not a problem but it is important that you understand that this may be what is happening.
Scenario 2: Upgrading Apps 11i to 12 updates the Global Inventory
Using the same starting scenario as above, if your R12 operating system user has write access to the Global Inventory created by 11i, then rapidwiz will update that Global Inventory with details of the new Oracle homes installed. Again, this is not a problem, but it is important that you are aware of what is happening.
When multiple Central Inventories exist, you must to be aware of this, as the correct Pointer File will need to be specified when maintaining the Oracle homes to maintain the correct Central Inventory.
Updating the Inventory When Removing an 11i or R12 environment
With the potential for single or multiple Global Inventories being created or updated, it’s important that when you delete an Oracle Applications environment from a machine, you make sure its corresponding Global Inventory entry is also updated correctly.
If your node is using a single Global Inventory and you wish to delete an Oracle Applications environment, it is not enough to just shut down the database and all the services and delete the software. This will leave a record of the installation in the Global Inventory.
To completely remove an installation, you must run OUI and use the graphical interface or the OUI command line to update the Global Inventory to record that the installation has been removed. If this is not done, then the Global Inventory retains a record of an environment that no longer exists on the node.
If you were to then perform a new installation or clone to that node at the same location as the previously removed installation, there would be a failure to correctly register the new installation. This could easily create an Oracle Applications installation which does not work correctly, or has links to non-existent locations. You might also have problems upgrading the technology stack or applying patches to this environment at a later date.
Tools for Managing the Inventory
Fortunately, there are various tools that allow you to check the condition of the Global Inventory on a node:
If you encounter a situation where your Oracle home is not correctly recorded in a Global Inventory, it is also possible to create or update the Central Inventory. There are several notes (see links in the Reference section below), which explain how to create or update the Central Inventory. There is also a note on how to consolidate multiple Central Inventories on a node into a single Central Inventory.
There is sometimes the temptation to manually edit the XML files that make up the Central or Home Inventory. Don't give in to temptation. The OUI Inventory should only be updated via Oracle tools such as the Oracle Universal Installer itself, the Rapid Install (rapidwiz), Opatch, and RapidClone.
Checking the OUI Inventory Log Files
During an installation or clone of Oracle Applications, the inventory creation or updating process is recorded in the log file called ohclone.log. The ohclone.log file will tell you if any aspect of the registration process has failed. You should always check this (and other log files) as part of your installation or cloning process.
Four Tips for Maintaining a Healthy Inventory
If you spend a lot of time installing and removing Oracle Applications environments and and have not really thought about the inventory in the past, you should keep the following in mind: