Important Points :
1) For Oracle Grid Infrastructure for a Cluster installations, note the following restrictions for the Oracle Grid Infrastructure binary home (Grid home):
■ It must not be placed under one of the Oracle base directories, including the Oracle base directory of the Oracle Grid Infrastructure installation owner.
■ It must not be placed in the home directory of an installation owner
During installation, ownership of the path to the Grid home is changed to root. This change causes permission errors for other installations.
2) Oracle software owner user named oracle or grid user's primary group should be Oracle Inventory group (oinstall)
3) Ensure that the user ID and group IDs are the same on each cluster member node.
4) Regarding same userid on all nodes.
/usr/sbin/useradd -u 1100 -g oinstall -G dba grid
above is the basic command to create a new user 'grid'
■ The -u option specifies the user ID. Using this command flag is optional, as
you can allow the system to provide you with an automatically generated user
ID number. However, you must make note of the user ID number of the user
you create for Oracle Grid Infrastructure, as you require it later during
preinstallation, and you must have the same user ID number for this user on
all nodes of the cluster.
■ The -g option specifies the primary group, which must be the Oracle
Inventory group. For example: oinstall.
■ The -G option specified the secondary group, which in this example is dba.
5) If you have created a path for the Oracle Clusterware home that is compliant with
Oracle Optimal Flexible Architecture (OFA) guidelines for Oracle software paths then you do not need to create an Oracle base directory. When OUI finds an OFA-compliant
path, it creates the Oracle base directory in that path.
For OUI to recognize the path as an Oracle software path, it must be in the form u[00-
99]/app, and it must be writable by any member of the oraInventory (oinstall)
group. The OFA path for the Oracle base is /u01/app/user, where user is the name
of the software installation owner.
6) operating system groups required
a) OSDBA group (typically, dba)
- This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege).
- If you do not designate a separate group as the OSASM group, then the OSDBA group you define is also by default the OSASM group.
- If you do not create separate OSDBA, OSOPER and OSASM groups for the Oracle ASM instance, then operating system user accounts that have the SYSOPER and SYSASM privileges must be members of this group.
- To specify a group name other than the default dba group, then you must choose the Advanced installation type to install the software
- Members of the OSDBA group formerly were granted SYSASM privileges on Oracle ASM instances, including mounting and dismounting disk groups. This privileges grant is removed with Oracle Grid Infrastructure 11g release 2, if different operating system groups are designated as the OSDBA and OSASM groups. If the same group is used for both OSDBA and OSASM, then the privilege is retained.In nutshell, only userids having OSASM group can only work with ASM instance
b) OSOPER group for Oracle Database (typically, oper)
- This is an optional group.
- By default, members of the OSDBA group also have all privileges granted by the SYSOPER privilege
c) OSASM group (typically, asmadmin)
- SYSASM is a new system privilege that enables the separation of the Oracle ASM storage administration privilege from SYSDBA.
- userid having OSASM group only can have the SYSASM privileges
- this is a required group.
- If you have multiple databases on your system, and use multiple OSDBA groups so that you can provide separate SYSDBA privileges for each database, then you
should create a separate OSASM group, and use a separate user from the database users to own the Oracle Grid Infrastructure installation (Oracle Clusterware and
Oracle ASM).
d) OSDBA for ASM (typically, asmdba)
- Members of the ASM Database Administrator group (OSDBA for ASM) are granted read and write access to files managed by Oracle ASM.
- The Oracle Grid Infrastructure installation owner and all Oracle Database software owners must be a member of this group, and all users with OSDBA membership on databases that
have access to the files managed by Oracle ASM must be members of the OSDBA group for ASM.
e) OSOPER for ASM (typically, asmoper)
- This is an optional group.
- Only if you want a separate group of operating system users to have a limited set of Oracle ASM instance administrative privileges (the SYSOPER for ASM privilege), including starting up and stopping the Oracle ASM instance.
f) Oracle central inventory group ( oinstall )
- Members who have the central inventory group as their primary group, are granted the OINSTALL permission to write to the oraInventory directory.
7) Directory permissions
- /u01/app owned by grid:oinstall with 775 permissions before installation, and by root after the root.sh script is run during installation
- /u01 owned by grid:oinstall before installation, and by root after the root.sh script is run during installation.
- /u01/app/11.2.0/grid owned by grid:oinstall with 775 permissions.
- /u01/app/grid owned by grid:oinstall with 775 permissions before installation, and 755 permissions after installation.
- /u01/app/oracle owned by oracle:oinstall with 775 permissions.
8) NIC bonding or Redundant Interconnect Usage?
Redundant Interconnect Usage is strongly recommended, since it is more flexible and versatile, than simple NIC bonding, since it does load balancing and failover at the same time (which NIC Bonding cannot do). So I would prefer going with the new feature.
If you still run older databases with 11.2 grid infrastructure you have to stay with NIC bonding though...