Local and Central Inventory Summary

It turns out that you get quite intimate, quite quickly with the Oracle Central Inventory when you’re maintaining Exadata systems. Like on any other RAC system, it is maintained across the cluster and any problems can quite quickly leave you unable to patch on all nodes. Here are a few things I’ve learned about the Oracle Central and Local inventories over the last year.

I should say from the start that much of this information has been gained from painful experience and often comes from some very talented individuals within Oracle support and development. It is now also starting to become quite well documented on MOS. However, unless you’re comfortable that you have extensively tested it in non-production environments I really wouldn’t follow this process at all on a production system. This isn’t the supported method for doing things, and this process is likely to become out of date quite quickly.

Central Inventory vs Local Inventory

The Central inventory is central to all homes on that node. It is basically a high level overview of the Oracle software installed on that particular host, it doesn’t in itself contain information about the patches but rather just a record of the path to the software, and which nodes the software is available on.

The Local Inventory is stored within the software home itself, and each Oracle Home has a local inventory within $ORACLE_HOME/inventory. This is a much more detailed record of the various components installed within that home and the patches contained within. It does also cross reference back to the Central Inventory, but more on this later.

I’m told by Oracle that the Central Inventory is very easy to break, but very easy to rebuild. On the other hand, the Local Inventory is very robust but if you do manage to corrupt it, then good luck fixing it! You’re probably looking at re installing it from another node in that case.

Central Inventory

This is the high level overview of all homes installed on that host. A pointer to the location of this inventory is usually located in /etc/oraInst.loc. The main file of interest within the central inventory is ContentsXML/inventory.xml. It is very important that you never make manual changes to this file (as with any other file within the Central or Local inventories!) but you’ll always want to keep a close eye on the contents of the file during patching and installations.

Important parts of this file include which nodes the software is installed on, the name of the home, the path to the software and an IDX value which is used within the Local Inventory (more on this later).

Local Inventory

This is the much more detailed inventory contained within ORACLE_HOME/inventory for each software installation. The most useful file (for me so far anyway) here has been the comps.xml. This references back to the Central Inventory by way of the HOME_IDX values (matches the IDX value from the Central Inventory). Note though, that these index values won’t necessarily match across the different nodes in the cluster. You will have major problems if they don’t at least match between the Local and Central Inventory on that particular node though.

Each Oracle Home has a pointer to the Central Inventory in ORACLE_HOME/oraInst.loc.

Modifying the inventory – adding, removing and rebuilding

Again, to clarify – we’re not making unsupported manual changes to the inventory here. And also, re-read what I said at the start of this article about not using these commands in a production environment. They have worked for me in the past, but I can’t guarantee they will work for you on your specific version!

The Central Inventory tracks the software installed on the host, and there are times where you might need to manually remove old software from the host. I’ve found this useful where we’ve performed out of place upgrades, and later decided to clean up and delete the old software. What we’ve done in this case is manually rename (mv) the unused software directories, remove it from the Central Inventory, and then a couple of weeks later delete (rm) the software.

To remove these old homes from the inventory, I have used the following command –

$ORACLE_HOME/oui/bin/runInstaller -detachHome -silent -local \
ORACLE_HOME=$HOME_PATH_TO_REMOVE

This takes that particular entry out of the Central Inventory on that local node. It then lets you move or remove that software from the host (assuming it isn’t in active use).

To add that software back into the inventory, you can use a command like this –

$ORACLE_HOME/oui/bin/runInstaller -silent -local -attachHome \
ORACLE_HOME="$HOME_PATH_TO_ADD" ORACLE_HOME_NAME="$HOME_NAME_TO_ADD" \
"CLUSTER_NODES={node1,node2,node3}" 

If this is a Grid Infrastructure home, we include CRS=TRUE at the end, ie –

$ORACLE_HOME/oui/bin/runInstaller -silent -local -attachHome \
ORACLE_HOME="$HOME_PATH_TO_ADD" ORACLE_HOME_NAME="$HOME_NAME_TO_ADD" \
"CLUSTER_NODES={node1,node2,node3}" CRS=TRUE

Now this last command turned out to be quite useful when fixing a corrupt inventory. The old Central Inventory can be backed up, and one by one for each home you remove and add back in each home required. This re-links it back to the local inventory and updates the IDX values.

Further Reading

Oracle has published a good MOS article which goes into a little more detail –

FAQs on Central Inventory and Oracle Home Inventory (Local Inventory) in Oracle RDBMS [ID 564192.1]

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: