Oracle Central Inventory Cleanup: detachHome, CRS Flags, and When They Get Confused for Each Other

Three problems, one file

Three different Oracle central-inventory problems tend to get lumped together under "stale home" — a patch or install refuses to proceed, someone greps inventory.xml, and the fix that gets reached for is whichever one worked last time. They're not the same mechanism, and the fix for one does nothing for the other two. Here's how to tell them apart.

Problem 1 — A home is still registered when it shouldn't be

Symptom, straight from a real install attempt:

[INS-32826] The software home (/u01/app/oracle/product/19.0.0/dbhome_xyz) is already registered
in the central inventory. Refer to patch readme instructions on how to apply.

Cause: the home path is already present in inventory.xml — often a pre-upgrade clusterware home nobody removed, or a DB home left behind after a migration.

Fix — Oracle's own two-step detachHome procedure (MOS Doc 1346305.1, duplicated as KB149122):

export ORACLE_HOME=$OLD_HOME

# Step 1: try the plain, cluster-wide detach
$OLD_HOME/oui/bin/runInstaller -detachHome -silent ORACLE_HOME=$OLD_HOME

# confirm it's gone from the central inventory
opatch lsinventory -all

# remove files if the home is genuinely no longer needed (optional, do it on every node)
/bin/rm -rf $OLD_HOME
unset ORACLE_HOME

If the plain command fails — and per the same MOS note, it can — fall back to the -local per-node variant. This is the exact command we've run successfully in practice, executed from the Grid home's oui/bin (not necessarily the target home's own, which may itself be broken):

runInstaller -silent -waitforcompletion -detachHome ORACLE_HOME='/path/to/old/home' -local

Run the -local version once per node where the home is still registered.

Problem 2 — A registered home's own inventory files aren't readable (OUI-10152)

Symptom, from a real precheck run:

[FATAL] OUI-10152:A runtime exception occurred during the execution of this query.
...
INFO: Unable to read inventory information for the home: /u01/.../dbhome_xyz.

or, more explicitly, from an internal precheck tool that walks every registered home before a GI upgrade:

[FAIL] /u01/.../dbhome_xyz/inventory/ContentsXML/comps.xml not readable as user oracle.
       gridSetup.sh/runInstaller.sh will fail. Review Doc ID KB753860
[FAIL] /u01/.../dbhome_xyz/inventory/ContentsXML/config.xml not readable as user oracle.
       gridSetup.sh/runInstaller.sh will fail. Review Doc ID KB753860.

Cause (Oracle's own text, MOS/KB753860): $ORACLE_HOME/inventory/ContentsXML/comps.xml (and config.xml) for a registered home isn't readable by the OS user running gridSetup.sh — typically the grid/ASM user.

The trap: gridSetup.sh walks every home still listed in the central inventory before it will proceed, not just the one you're installing or patching. A single long-forgotten, unrelated home with a permissions problem on its own comps.xml is enough to fail an otherwise unrelated GI setup or upgrade with this generic-looking runtime exception.

This is a different failure from Problem 1. The home in Problem 1 is registered and shouldn't be (it needs removing). The home here might still be perfectly valid and in use — it just has a file-permission problem in its own private inventory folder.

Diagnosis — check every registered home, not just the one causing trouble:

grep -i "HOME NAME" /u01/app/oraInventory/ContentsXML/inventory.xml

# for each home found, as the grid/ASM user:
su - grid -c "[ -r /path/to/home/inventory/ContentsXML/comps.xml ] && echo OK || echo UNREADABLE"

Fix: correct the permissions so the grid/ASM user can read comps.xml/config.xml for that home. Only reach for detachHome (Problem 1's fix) if you've confirmed the home is genuinely stale and unneeded — otherwise you're removing something that still works, just because its permissions were wrong.

Problem 3 — The wrong home is flagged as the active clusterware home (CRS=true)

Symptom: clusterware or database utilities that need to know "which home is the current GI home" fail or behave inconsistently — often after an upgrade, when the flag didn't move over to the new home.

Cause (Oracle's own text, MOS KB65507): a handful of clusterware utilities depend on the CRS=true flag in the central inventory to identify the current clusterware home. Only one home per node may carry it. If it's still set on the pre-upgrade home — or missing from the new one — those utilities get confused about which is authoritative.

This exact mechanism is also Step 9 of Oracle's own documented procedure for out-of-place GI home patching: after switching to the new Grid home, the central inventory is explicitly updated to reflect it.

Diagnosis:

cat /u01/app/oraInventory/ContentsXML/inventory.xml | grep -i CRS

Fix — Oracle's documented mechanism is -updateNodeList, never detachHome (which would remove the home from the inventory entirely rather than just correct a flag on a home that should stay registered):

# mark the new/correct home as active
runInstaller -updateNodeList ORACLE_HOME='/u01/app/19.0.0.0/grid' CRS=true

# unset it on the old home, if it's still registered
runInstaller -updateNodeList ORACLE_HOME='/path/to/old/grid/home' CRS=false

On a RAC cluster, add CLUSTER_NODES='{node1,node2,...}' and LOCAL_NODE='<node>' (or -local) to scope the change per node — the same pattern Oracle's own field recovery procedures use when correcting this flag after a failed or partial upgrade.

Telling them apart

The three problems, at a glance:

• Problem 1 (stale registration, INS-32826): the home is genuinely gone but still registered — fix with detachHome and optionally rm -rf; official source: MOS Doc 1346305.1 / KB149122
• Problem 2 (unreadable inventory files, OUI-10152): the home may still be valid, just has wrong permissions on comps.xml/config.xml — fix with chmod; reaching for detachHome here removes a home that may still be needed; official source: KB753860
• Problem 3 (wrong CRS flag): the home is correct and registered, just carrying the wrong flag — fix with -updateNodeList ... CRS=true/false; detachHome doesn't touch the flag at all; official source: KB65507

The takeaway