srvctl add oraclehome

Recently I was installing some new databases homes on some Exadatas and I was wondering how the Homes were "known" by the cluster (indeed, when rac-status.sh shows the Homes, I got them as a characteristic of a database and not from a list of registered homes) and I then found this srvctl add oraclehome option. This was on a 12.2 GI and honestly I never noticed it before.

The command help looks like this:

[root@exadatadb01]# srvctl add oraclehome -h
Adds the Oracle home resource to the Oracle Clusterware.
Usage: srvctl add oraclehome -name  -path  [-type {ADMIN|POLICY}] [-node ]
    -name               Identifier for the Oracle home resource
    -path               Oracle home path
    -type               {ADMIN|POLICY}      Type of the specified Oracle home. Default is POLICY.
    -node               Comma-separated list of nodes in which the Oracle home will be available
    -help               Print usage
[root@exadatadb01]#

I then tried to add my new home in my cluster and could check it:

[oracle@exadatadb01]$ srvctl add oraclehome -name TEST -path /u01/app/oracle/product/12.2.0.1/dbhome_2 -type admin -node exadatadb01,exadatadb02
[oracle@exadatadb01]$ srvctl config oraclehome -name TEST
Oracle home path: /u01/app/oracle/product/12.2.0.1/dbhome_2
Oracle home name: test
Oracle home type: ADMIN
Node list: exadatadb01,exadatadb02
Shared: FALSE
Oracle base: /u01/app/oracle
Databases configured:
Listeners configured:
Oracle home test is enabled.
Oracle home resource is individually enabled on nodes:
Oracle home resource is individually disabled on nodes:
[oracle@exadatadb01]$

And we can have information about this home using crsctl as well:

[root@exadatadb01]# crsctl stat res -p -w "TYPE = ora.home.type"
NAME=ora.test.home
TYPE=ora.home.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIONS=
ACTION_SCRIPT=
ACTION_TIMEOUT=60
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
. . .

Cool, huh ? now the question is "what is the use of that ?" indeed, I have checked on the other RAC/GI systems I have handy and no ORACLE_HOME is registered in the clusters, not in any configuration. We could also wonder what would be the use of having an ORACLE_HOME registered in the cluster ? an ORACLE_HOME is just some files and directories in a filesystem, what could be the value of CRS knowing about the ORACLE_HOME ? I then tried to google and MOS about this srvctl add oraclehome command and I absolutely found nothing !

As I do not like to keep things I do not understand their use, I decided to unregister my TEST ORACLE_HOME to keep a clean cluster configuration:

[oracle@exadatadb01]$ srvctl remove oraclehome -name TEST

Which worked fine. Then I thought I could do more testing on this feature and registered my home again:

[oracle@exadatadb01]$ srvctl add oraclehome -name TEST -path /u01/app/oracle/product/12.2.0.1/dbhome_2 -type admin -node exadatadb01,exadata02
PRCS-1085 : Server category test already exists 
PRCR-1086 : server category test is already registered

Which didn't work as it seems that the srvctl remove oraclehome left some categories behind which I found no way to remove (yet). A MOS SR gave me the information that I was hitting this bug:

Bug 25978527 - LNX64-12.2-SRVCTL:SRVCTL REMOVE ORACLEHOME SHOULD ALSO REMOVE CATEGORY CASCADELY 

. . . which I can acces no information about it so I don't know if there is a patch or a workaround for this.

To sum that up, I am not sure about the use of registering an ORACLE_HOME in the cluster, I found no information about this nowhere (google, MOS) and ... the remove oracle_home does not work properly so ... let's say that this feature is good to know and let's see if it becomes a real new feature in the future ! Let me know in the comments if you have a clue about a potential use of this.

An interesting point here though is that CRS not being aware of the ORACLE_HOMEs, GI is then also not aware of the versions of the ORACLE_HOMEs running there and then the pre-requisite saying that GI version has to be >= DB version cannot be enforced by GI -- which I tested and I can assure that it is indeed the case and you can run a DB Home version > GI version with no issue -- well except that it is not supported but it works with no problem as GI is not aware about the DB Home version :)