Introduction

When applying an Out-Of-Place patch to Oracle Grid Infrastructure or an Oracle Database using a fresh new Oracle Home, you must ensure that the new binaries are assigned to the same groups as the existing binaries.

For example, some environments simply use the “dba” or “oinstall” groups for OSDBA, OSOPER, and OSASM definitions. However, it is also very common to have specific groups for each role.

This presents a challenge: if you installed the environment yourself or are very familiar with it, you likely know which groups to use. But if you aren’t sure which groups were used in the current GI or DB home, you can inspect the file $ORACLE_HOME/rdbms/lib/config.c as I described in the old blog post “Como Saber Quais Grupos do Sistema Operacional Foram Usados na Instalação do Oracle Grid Infrastructure / Database ?“.

I also created the script get_groups.sh that I have been using a lot during my Out-Of-Place patching operations over the last few years. You can check how this script works in another old post here “Script get_groups.sh – Listando Os Grupos de SO de Um ORACLE_HOME“.

Please note these old blog post are in Brazilian Portuguese, but you can translate it in your browser.

How this works for 19c

For example, in the following Oracle RAC 19c, the current Grid home is “/u01/app/19.0.0.0/grid_1” and it was installed using only the oinstall group assigned to all OSDBA, OSOPER and OSASM options:

[grid@c02db01 ~]$ ps -ef | grep crsd.bin
root      268927       1  0 Mar31 ?        00:26:13 /u01/app/19.0.0.0/grid_1/bin/crsd.bin reboot
[grid@c02db01 ~]$ 
[grid@c02db01 ~]$ ~/get_groups.sh -oui -home /u01/app/19.0.0.0/grid_1
oracle.install.asm.OSDBA=oinstall
oracle.install.asm.OSOPER=oinstall
oracle.install.asm.OSASM=oinstall
[grid@c02db01 ~]$

We also need to check what is the current ORACLE_BASE used for this Grid home:

[grid@c02db01 ~]$ /u01/app/19.0.0.0/grid_1/bin/orabase
/u01/app/grid

And we also need to know what is the current Oracle Inventory location and the installation group:

[grid@c02db01 ~]$ cat /etc/oraInst.loc 
inventory_loc=/u01/app/oraInventory
inst_group=oinstall

Finally, we can use a command like this to install a new Grid Home with the correct settings:

export NEW_GIHOME=/u01/app/19.0.0.0/grid_2

$NEW_GIHOME/gridSetup.sh -ignorePrereq -waitforcompletion -silent \
-responseFile $NEW_GIHOME/install/response/gridsetup.rsp \
ORACLE_BASE=/u01/app/grid  \
INVENTORY_LOCATION=/u01/app/oraInventory \
UNIX_GROUP_NAME=oinstall \
SELECTED_LANGUAGES=en \
oracle.install.option=CRS_SWONLY \
ORACLE_HOME=${NEW_GIHOME} \
oracle.install.asm.OSDBA=oinstall \
oracle.install.asm.OSOPER=oinstall \
oracle.install.asm.OSASM=oinstall \
oracle.install.crs.config.ClusterConfiguration=STANDALONE \
oracle.install.crs.config.autoConfigureClusterNodeVIP=false \
oracle.install.crs.config.clusterNodes=c02db01,c02db02

How this Was Improved Starting with 23ai

The 23ai release introduced the -setupHomeAs option for gridSetup.sh and runInstaller. This option takes an existing Oracle Home as an argument to discover the correct settings automatically and apply them to the new Oracle Home. This significantly simplifies the installation of new binaries during Out-of-Place (OOP) patching.

In this example, I have another Oracle RAC with Grid Infrastructure and Oracle Database 23ai. The current Grid home is /u01/app/23.0.0.0/grid_3, which was installed using asmdba, asmoper, and asmadmin for the OSDBA, OSOPER, and OSASM groups, respectively.

[grid@c03db01 ~]$ ps -ef | grep crsd.bin
root        5645       1  0 Mar31 ?        00:18:48 /u01/app/23.0.0.0/grid_3/bin/crsd.bin reboot
[grid@c03db01 ~]$ 
[grid@c03db01 ~]$ 
[grid@c03db01 ~]$ ~/get_groups.sh -oui -home /u01/app/23.0.0.0/grid_3
oracle.install.asm.OSDBA=asmdba
oracle.install.asm.OSOPER=asmoper
oracle.install.asm.OSASM=asmadmin
[grid@c03db01 ~]$ 

But now the only thing that I need to know here is the current Oracle Home, so I can just use it in the -setupHomeAs option in the gridSetup.sh.

To install a new Grid Home as /u01/app/23.0.0.0/grid_1 using the same settings from the existing /u01/app/23.0.0.0/grid_3, we can just use a command like the following:

Single

<NEW_GI_HOME>/gridSetup.sh -silent -setupHomeAs <CURRENT_GI_HOME>

Cluster

If we are working in a Oracle RAC, we should include the cluster nodes:

<NEW_GI_HOME>/gridSetup.sh -silent \
 -setupHomeAs <CURRENT_GI_HOME> \
 -clusterNodes node1,node2,nodeN

Demo

Demo using it in a 6-Node RAC cluster:

Please note I’m using the env variable OLD_GI_HOME with the existing Grid Home, and the NEW_GI_HOME is the new GI home being installed.

[grid@c03db01 ~]$ export NEW_GI_HOME=/u01/app/23.0.0.0/grid_1
[grid@c03db01 ~]$ export OLD_GI_HOME=/u01/app/23.0.0.0/grid_3
[grid@c03db01 ~]$
[grid@c03db01 ~]$ unzip -q LINUX.X64_2326100_grid_home.zip -d $NEW_GI_HOME
[grid@c03db01 ~]$
[grid@c03db01 ~]$ $NEW_GI_HOME/gridSetup.sh -silent \
 -setupHomeAs $OLD_GI_HOME \
 -clusterNodes c03db01,c03db02,c03db03,c03db04,c03db05,c03db06
Launching Oracle Grid Infrastructure Setup Wizard...
The response file for this session can be found at:
 /u01/app/23.0.0.0/grid_1/install/response/grid_2026-04-05_03-20-59PM.rsp
You can find the log of this install session at:
 /u01/app/oraInventory/logs/GridSetupActions2026-04-05_03-20-59PM/gridSetupActions2026-04-05_03-20-59PM.log
As a root user, run the following script(s):
        1. /u01/app/23.0.0.0/grid_1/root.sh
Run /u01/app/23.0.0.0/grid_1/root.sh on the following nodes: 
[c03db01, c03db02, c03db03, c03db04, c03db05, c03db06]
Successfully Setup Software.

And if we compare the groups at end, they should be the same:

[grid@c03db01 ~]$ 
[grid@c03db01 ~]$ ~/get_groups.sh -home /u01/app/23.0.0.0/grid_1
OSDBA=asmdba,OSOPER=asmoper,OSASM=asmadmin
[grid@c03db01 ~]$ 
[grid@c03db01 ~]$ ~/get_groups.sh -home /u01/app/23.0.0.0/grid_3
OSDBA=asmdba,OSOPER=asmoper,OSASM=asmadmin
[grid@c03db01 ~]$ 

About DB Home

This feature works in the same way to install new DB Home, where you can just use the -setupHomeAs in the runInstaller, and inform an existing Oracle Home as argument. If the environment is an Oracle RAC, we also need to include the cluster nodes.

Cluster Nodes Requirements

This is something I think that Oracle could improve in the future, the -setupHomeAs could identify the cluster nodes automatically from the existing binary as well. Currently if you we don’t specificy the cluster nodes explicitily, the new binary get installed in the local node only.

Conclusion

In this post, we have seen how Out-of-Place patching has become even easier in newer releases. Starting with 23ai, the process is less error-prone and much better suited for automation. It is important to note that it is still possible to install the new GI or DB Home using the old syntax (as demonstrated for 19c); however, I recommend using the new syntax to simplify your work and mitigate common OOP errors, like using the wrong OS groups for new binaries.