The Latest Oracle E-Business Suite Technology News direct from
Oracle E-Business Suite Development & Product Management

Oracle Universal Installer Inventory Essentials for Apps Sysadmins

Steven Chan
Senior Director

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).

Screenshot of generic Oracle Universal Installer dialog box

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:

  • The Pointer File
  • The Central (Global) Inventory
  • The Home (Local) Inventory

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:

  • The Opatch utility has some useful command line parameters which allow you to interrogate and report on the condition of the inventory.  
  • OUI and OPatch also support the “invPtrLoc” parameter which allows you to specify the inventory Pointer File you wish to use when you install or patch a product.

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:

  1. Always deinstall the Oracle Applications technology stack using the OUI before deleting the software.
  2. Always check the ohclone.log after an installation or clone.
  3. If you know how your OUI Inventory is currently arranged, you should be fine. If you don’t, you should take a little time to familiarise yourself with the setup.
  4. Do not try to manually edit files that make up the Global or Local Inventory.


Join the discussion

Comments ( 6 )
  • Robin Chatterjee Monday, August 10, 2009

    Previously the use of a single central inventory was an oracle best practise ( r11). What Would you say that the current best practise for (r12) is ?

    Would you recommend a single central inventory or multiple individual ones ?



  • Nick Quarmby Monday, August 10, 2009

    Hi Robin

    I think it depends on how you plan to use the node in the future. If you're going to have a mix of 11i and R12 environments on the node then it may be easier to use a single Central inventory. If you only plan to have a single R12 environment on the box then it may be easier just to go with the default R12 setup.

    It's really up to you, it's just important you know what setup you have otherwise you will find maintaining Oracle homes gets confusing when you come to apply patches or run OUI for any reason.



  • Steve Peters Monday, August 10, 2009

    Thanks Steven - another great article. I have one question: does OEM now integrate well with multiple central inventories. Several years ago I had to evaluate OEM with a server that had over 50 oracle homes spread over dozens of central inventories. The OEM automatic discovery at that time could only use a single central inventory.

    Regards, Steve

  • Nick Quarmby Tuesday, August 11, 2009

    Hi Steve

    The latest Enterprise Manager Concepts manual (http://download.oracle.com/docs/cd/B16240_01/doc/em.102/b31949.pdf) certainly suggests that this is now possible....

    "Enterprise Manager uses the Oracle Universal Installer inventory or inventories on a host to obtain information about the Oracle products installed on the host."

    I'd suggest you revisit your evaluation and perhaps also take a look at the Applications Management Pack which is a plug-in to Enterprise Manager / Grid Control and is specifically for managing Oracle Applications environments. Steven has previewed this most recently at http://blogs.oracle.com/stevenChan/2009/06/amp_acmp_certified_with_emgcr5.html

    If you want to check in more detail about EM support for multiple central inventories then an exploratory Service Request with the Enterprise Manager group might also be a good idea.



  • TVC Friday, August 14, 2009

    It's actually a sad message, because it could be read as : in 11i, we had persistency in trying to maintain the central inventory.

    In R12 however, we have given up to achieve the goal, and we have no good solution for it. Keep in mind, that the "central" inventory always had the architectural idea to be ... euhm, central. As in : one per server. Not inside every single Oracle Home. A "central" inventory inside an Oracle Home, is pretty useless. Actually, it will cause more problems than it will try to solve.

    The problem is that root-access is not always granted, from the OS system administrator, to the Oracle system administrator. This is, what I think, reasonable and in the line of expectations.

    Apps should think 1 step further. OK, if we don't get root-access (which really, we don't often need), we could do with some sort of another account. Something between root and applmgr/oracle. Why would root be the ONLY user being able to write into /var/opt/oracle ... there's no such limitation, other than the one imposed by careless usage of the content of this structure.

  • Nick Quarmby Sunday, August 16, 2009

    Hi TVC

    Thanks for your comments.

    I believe the 11i and R12 implementations of the Central inventory both have their merits. Having an environment where the Central Inventory is self-contained within the application directory structure could be seen by many to be a more elegant and sometimes pragmatic solution.

    I certainly don't think we've given up. My understanding is that one of the drivers for multiple Central Inventories was a need to be able to upgrade multiple Oracle homes on a node simultaneously. The inventory has a locking system making this impossible if there is only a single Central Inventory.



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.