3 Oracle Real Application Clusters Preinstallation Tasks

This chapter describes the system configuration tasks that are generally completed by the system administrator if you plan to install Oracle Database or Oracle Database with Oracle Real Application Clusters (Oracle RAC). These tasks include creating additional groups and users for the database and for Automatic Storage Management (ASM).

You must complete these tasks before you or a database administrator start Oracle Universal Installer to install Oracle RAC. If you do not plan on installing Oracle Database on this cluster, then you can continue to the next chapter.

This chapter contains the following topics:

Note:

Any task required for Oracle Database is also required for Oracle RAC, unless otherwise stated.

3.1 Creating Standard Configuration Operating System Groups and Users

A standard configuration is a configuration with the default groups and users that Oracle Universal Installer (OUI) displays by default during Oracle database installation, which are not created already for Oracle Clusterware installation.

The following sections describe how to create the required operating system user and groups for Oracle Database or Oracle Database with Oracle RAC and ASM installations:

To allocate separate operating system user privileges to different administrative users, refer to "Creating Custom Configuration Groups and Users for Job Roles".

3.1.1 Overview of Groups and Users for Oracle Database Installations

The following operating system groups and user are required if you plan to install Oracle Database:

  • The OSDBA group (typically, dba)

    You must create this group the first time you install Oracle Database software on the system. In a standard installation, you are prompted to one group to grant the following privileges to its members:

    • Database Administrator (OSDBA)

    • Database Operator (OSOPER)

    • ASM Administrator (OSASM)

    In addition, members of this group are granted database write access to ASM (OSDBA for ASM).

    The default name for this group is dba.

  • An unprivileged user

    Verify that the unprivileged user nobody exists on the system. The nobody user must own the external jobs (extjob) executable after the installation.

3.1.2 Creating Standard Operating System Groups and Users

The following sections describe how to create required and optional operating system user and groups:.

3.1.2.1 Verifying That the User nobody Exists

If you intend to install Oracle Database or Oracle RAC, then complete the following procedure to verify that the user nobody exists on the system:

  1. To determine if the user exists, enter the following command:

    # id nobody
    

    If this command displays information about the nobody user, then you do not have to create that user.

  2. If the nobody user does not exist, then enter a command similar to the following to create it:

    # /usr/sbin/useradd -u 65001 nobody
    
  3. Repeat this procedure on all the other nodes in the cluster. Note that the ID number for uid and gid should be the same on all nodes of the cluster.

3.1.2.2 Creating the OSDBA Group

To create the OSDBA group, complete the following procedure:

  1. Enter a command similar to the following:

    # /usr/sbin/groupadd -g 502 dba
    

    The preceding command creates the group dba, with the group ID number 502.

3.1.2.3 Creating Identical Users and Groups on Other Cluster Nodes

Note:

You must complete the following procedures only if you are using local users and groups. If you are using users and groups defined in a directory service such as NIS, then they are already identical on each cluster node.

Oracle software owner users and groups must exist and be identical on all cluster nodes.

Identifying Existing User and Group IDs

To determine the user ID (UID) of the oracle user, and the group IDs (GID) of the Oracle Inventory, OSDBA, and OSOPER groups, follow these steps:

  1. Enter a command similar to the following (in this case, to determine a user ID):

    # id oracle
    

    The output from this command is similar to the following:

    uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper),506(asmdba)
    
  2. From the output, identify the user ID (UID) for the user and the group identities (GIDs) for the groups to which it belongs. Ensure that these are identical on each node.

Creating Users and Groups on the Other Cluster Nodes

To create users and groups on the other cluster nodes, repeat the following procedure on each node:

  1. Log in to the next cluster node as root.

  2. Enter commands similar to the following to create groups. Use the -g option to specify the correct GID for each group.

    # /usr/sbin/groupadd -g 501 oinstall
    # /usr/sbin/groupadd -g 502 dba
    

    Note:

    If a group already exists, but has a different group ID, then use the groupmod command to modify it if necessary. If you cannot use the same group ID for a particular group on this node, then view the /etc/group file on all nodes to identify a group ID that is available on every node. You must then specify that ID for the group on all of the nodes.
  3. To create the oracle user or another required user, enter a command similar to the following (in this example, to create the oracle user):

    # /usr/sbin/useradd -u 501 -g oinstall oracle
    

    In the preceding command:

    • The -u option specifies the user ID, which must be the user ID that you identified in the previous subsection

    • The -g option specifies the primary group, which must be the Oracle Inventory group; for example, oinstall

    • Note:

      If the user already exists, then use the usermod command to modify it if necessary. If you cannot use the same user ID for the user on this node, then view the /etc/passwd file on all nodes to identify a user ID that is available on every node. You must then specify that ID for the user on all of the nodes.
  4. Set the password of the user. For example:

    # passwd oracle
    

3.2 Creating Custom Configuration Groups and Users for Job Roles

A Custom configuration is a configuration with groups and users that divide access privileges granted by membership in separate operating system groups and users.

Note:

This configuration is optional, to restrict user access to Oracle software by responsibility areas for different administrator users.

To allocate operating system user privileges to a minimum number of groups and users, refer to Creating Standard Configuration Operating System Groups and Users.

Note:

If you want to use a directory service, such as Network Information Services (NIS), refer to your operating system documentation for further information.

3.2.1 Overview of Creating Operating System Group and User Options Based on Job Roles

This section provides an overview of how to create users and groups to divide access privileges by job roles. Log in as root to create these groups and users.

3.2.1.1 Users for Oracle Installations with Job Role Separation

Oracle recommends that you create the following operating system group and users for all installations where you create separate software installation owners:

  • One software owner to own each Oracle software product (typically, oracle, for the database software owner user, crs for Oracle Clusterware, and asm for Oracle ASM.

    You must create at least one software owner the first time you install Oracle software on the system. This user owns the Oracle binaries of the Oracle Clusterware software, and you can also make this user the owner of the binaries of Automatic Storage Management and Oracle Database or Oracle RAC.

    Oracle software owners must have the Oracle Inventory group as their primary group, so that each Oracle software installation owner can write to the Central Inventory, and so that OCR and Oracle Clusterware resource permissions are set correctly. The Database software owner must also have the OSDBA group and (if you create it) the OSOPER group as secondary groups. In Oracle documentation, when Oracle software owner users are referred to, they are called oracle users.

    Oracle recommends that you create separate software owner users to own each Oracle software installation. Oracle particularly recommends that you do this if you intend to install more than one database on the system.

    In Oracle documentation, a user created to own the Oracle Clusterware binaries is called the crs user.

    If you intend to use Automatic Storage Management (ASM), then Oracle recommends that you create a separate user to own ASM files. In Oracle documentation, that user is referred to as asm.

    See Also:

    Oracle Database Administrator's Reference for UNIX Systems and Oracle Database Administrator's Guide for more information about the OSDBA, OSASM and OSOPER groups and the SYSDBA, SYSASM and SYSOPER privileges
  • An unprivileged user

    Verify that the unprivileged user nobody exists on the system. The nobody user must own the external jobs (extjob) executable after the installation.

3.2.1.2 Database Groups for Job Role Installations

The following operating system groups and user are required if you are installing Oracle Database:

  • The OSDBA group (typically, dba)

    You must create this group the first time you install Oracle Database software on the system. This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege). If you do not create separate OSDBA, OSOPER and OSASM groups for the ASM instance, then operating system user accounts that have the SYSOPER and SYSASM privileges must be members of this group. The name used for this group in Oracle code examples is dba. 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 want to specify a group name other than the default dba group, then you must choose the Custom installation type to install the software or start Oracle Universal Installer (OUI) as a user that is not a member of this group. In this case, OUI prompts you to specify the name of this group.

    On Automatic Storage Manager (ASM) instances, members of the OSDBA group are given privileges to perform all administrative privileges granted to the SYSASM privileges, including mounting and dismounting disk groups. This privileges grant is deprecated, and will be removed in a future release.

  • The OSOPER group for Oracle Database (typically, oper)

    This is an optional group. Create this group if you want a separate group of operating system users to have a limited set of database administrative privileges (the SYSOPER privilege). By default, members of the OSDBA group also have all privileges granted by the SYSOPER privilege.

    If you want to use the OSOPER group to create a database administrator group with fewer privileges than the default dba group, then you must choose the Custom installation type to install the software or start OUI as a user that is not a member of the dba group. In this case, OUI prompts you to specify the name of this group. The usual name chosen for this group is oper.

3.2.1.3 ASM Groups for Job Role Installations

SYSASM is a new system privilege that enables the separation of the ASM storage administration privilege from SYSDBA. Members of the database OSDBA group are granted SYSASM privileges, but this privilege is deprecated, and may be removed in a future release.

Use the Custom Installation option to designate separate operating system groups as the operating system authentication groups for privileges on ASM. Before you start OUI, create the following groups and users for ASM

  • The Oracle Automatic Storage Management Group (typically asm)

    SYSASM privileges for ASM files provide administrator privileges for storage file equivalent to SYSDBA privileges for the database. In Oracle documentation, the operating system group whose members are granted SYSASM privileges is called the OSASM group, and in command lines, is referred to as asm.

    If you have more than one database on your system, then you must create a separate OSASM group, and a separate ASM user. ASM can support multiple databases.

    Members of the OSASM group can use SQL to connect to an ASM instance as SYSASM using operating system authentication. The SYSASM privileges permit mounting and dismounting disk groups, and other storage administration tasks. SYSASM privileges provide no access privileges on an RDBMS instance. In this release of Oracle Clusterware and Oracle Database, SYSASM privileges and SYSDBA privileges are equivalent, but using SYSDBA privileges to perform ASM management tasks on ASM instances is deprecated. SYSDBA privileges may be limited on ASM instances in a future release.

  • The OSDBA group for ASM (typically asmdba)

    Members of the OSDBA group for ASM are granted read and write access to files managed by ASM. The Oracle database software owner (typically oracle) must be a member of this group, and all users with OSDBA membership on databases that you want to have access to the files managed by ASM should be members of the OSDBA group for ASM

3.2.2 Creating Database Operating System Groups and Users with Job Role Separation

The following sections describe how to create the required operating system user and groups:.

3.2.2.1 Creating the OSDBA Group for Custom Installations

You must create an OSDBA group in the following circumstances:

  • An OSDBA group does not exist, for example, if this is the first installation of Oracle Database software on the system

  • An OSDBA group exists, but you want to give a different group of operating system users database administrative privileges for a new Oracle Database installation

If the OSDBA group does not exist or if you require a new OSDBA group, then create it as follows. In the following procedure, use the group name dba unless a group with that name already exists:

# /usr/sbin/groupadd -g 502 dba

3.2.2.2 Creating an OSOPER Group

Create an OSOPER group only if you want to identify a group of operating system users with a limited set of database administrative privileges (SYSOPER operator privileges). For most installations, it is sufficient to create only the OSDBA group. If you want to use an OSOPER group, then you must create it in the following circumstances:

  • If an OSOPER group does not exist; for example, if this is the first installation of Oracle Database software on the system

  • If an OSOPER group exists, but you want to give a different group of operating system users database operator privileges in a new Oracle installation

If you require a new OSOPER group, then create it as follows. In the following, use the group name oper unless a group with that name already exists.

# /usr/sbin/groupadd -g 505 oper

3.2.2.3 Creating the OSASM Group

If the OSASM group does not exist or if you require a new OSASM group, then create it as follows. In the following procedure, use the group name asm unless a group with that name already exists:

# /usr/sbin/groupadd -504 asm

3.2.2.4 Creating the OSDBA Group for ASM

You must create an OSDBA group for ASM to provide access to the ASM instance. This is necessary if OSASM and OSDBA are different groups.

If the OSDBA group for ASM does not exist or if you require a new OSDBA group for ASM, then create it as follows. In the following procedure, use the group name asmdba unless a group with that name already exists:

# /usr/sbin/groupadd -g 506 asmdba

3.2.2.5 Creating the Oracle Software Owner User

You must create an Oracle software owner user in the following circumstances:

  • If an Oracle software owner user exists, but you want to use a different operating system user, with different group membership, to give database administrative privileges to those groups in a new Oracle Database installation

  • If you have created an Oracle software owner for Oracle Clusterware, such as crs, and you want to create a separate Oracle software owner for Oracle Database software, such as dba.

3.2.2.5.1 Determining if an Oracle Software Owner User Exists

To determine whether an Oracle software owner user named oracle or crs exists, enter a command similar to the following (in this case, to determine if oracle exists):

# id oracle

If the user exists, then the output from this command is similar to the following:

uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)

Determine whether you want to use the existing user, or create another user. If you want to use the existing user, then ensure that the user's primary group is the Oracle Inventory group and that it is a member of the appropriate OSDBA and OSOPER groups. Refer to one of the following sections for more information:

Note:

If necessary, contact your system administrator before using or modifying an existing user.
3.2.2.5.2 Creating an Oracle Software Owner User

If the Oracle software owner user does not exist, or if you require a new Oracle software owner user, then create it as follows. In the following procedure, use the user name oracle unless a user with that name already exists.

  1. To create an oracle user, enter a command similar to the following:

    # /usr/sbin/useradd -u 502 -g oinstall -G dba oracle
    

    In the preceding command:

    • 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 oracle user ID number, as you require it later during preinstallation.

    • The -g option specifies the primary group, which must be the Oracle Inventory group--for example, oinstall

    • The -G option specifies the secondary groups, which must include the OSDBA group, and, if required, the OSOPER group. For example: dba, or dba,oper

  2. Set the password of the oracle user:

    # passwd oracle
    
3.2.2.5.3 Modifying an Existing Oracle Software Owner User

If the oracle user exists, but its primary group is not oinstall, or it is not a member of the appropriate OSDBA or OSOPER groups, then enter a command similar to the following to modify it. Specify the primary group using the -g option and any required secondary group using the -G option:

# /usr/sbin/usermod -g oinstall -G dba[,oper] oracle

Repeat this procedure on all of the other nodes in the cluster.

3.2.2.6 Creating a Separate ASM Owner

  1. To create asm, enter a command similar to the following:

    # /usr/sbin/useradd -u 504 -g oinstall -G asm asm
    

    In the preceding command:

    • 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 asm ID number, as you require it later during preinstallation.

    • The -g option specifies the primary group, which must be the Oracle Inventory group--for example, oinstall

    • The -G option specifies the secondary groups, which must include the OSASM group. For example: asm.

  2. Set the password for asm:

    # passwd asm
    

3.2.2.7 Verifying That the User nobody Exists

Before installing the software, complete the following procedure to verify that the user nobody exists on the system:

  1. To determine if the user exists, enter the following command:

    # id nobody
    

    If this command displays information about the nobody user, then you do not have to create that user.

  2. If the nobody user does not exist, then enter the following command syntax to create it:

    # /usr/sbin/useradd -u number nobody
    

    for example:

    # /usr/sbin/useradd -u 65555 nobody
    
  3. Repeat this procedure on all the other nodes in the cluster.

3.2.2.8 Creating Identical Database Users and Groups on Other Cluster Nodes

Note:

You must complete the following procedures only if you are using local users and groups. If you are using users and groups defined in a directory service such as NIS, then they are already identical on each cluster node.

Oracle software owner users and the Oracle Inventory, OSDBA, and OSOPER groups must exist and be identical on all cluster nodes. To create these identical users and groups, you must identify the user ID and group IDs assigned them on the node where you created them, and then create the user and groups with the same name and ID on the other cluster nodes.

Identifying Existing User and Group IDs

To determine the user ID (UID) of the crs, oracle, or asm users, and the group IDs (GID) of the Oracle Inventory, OSDBA, and OSOPER groups, follow these steps:

  1. Enter a command similar to the following (in this case, to determine a user ID for the oracle user):

    # id oracle
    

    The output from this command is similar to the following:

    uid=502(oracle) gid=501(oinstall) groups=502(dba),503(oper)
    
  2. From the output, identify the user ID (UID) for the user and the group identities (GIDs) for the groups to which it belongs. Ensure that these ID numbers are identical on each node of the cluster.

Creating Users and Groups on the Other Cluster Nodes

To create users and groups on the other cluster nodes, repeat the following procedure on each node:

  1. Log in to the next cluster node as root.

  2. Enter commands similar to the following to create the oinstall and dba groups, and if required, the oper and asm groups. Use the -g option to specify the correct GID for each group.

    # /usr/sbin/groupadd -g 501 oinstall
    # /usr/sbin/groupadd -g 502 crs
    # /usr/sbin/groupadd -g 503 dba
    # /usr/sbin/groupadd -g 505 oper
    # /usr/sbin/groupadd -g 504 asm
    # /usr/sbin/groupadd -g 506 asmdba
    

    Note:

    If the group already exists, then use the groupmod command to modify it if necessary. If you cannot use the same group ID for a particular group on this node, then view the /etc/group file on all nodes to identify a group ID that is available on every node. You must then change the group ID on all nodes to the same group ID.
  3. To create the oracle or asm user, enter a command similar to the following (in this example, to create the oracle user):

    # /usr/sbin/useradd -u 502 -g oinstall -G dba[,oper] oracle
    

    In the preceding command:

    • The -u option specifies the user ID, which must be the user ID that you identified in the previous subsection

    • The -g option specifies the primary group, which must be the Oracle Inventory group, for example oinstall

    • The -G option specifies the secondary groups, which must include the OSDBA group and if required, the OSOPER group. For example: dba or dba,oper

      Note:

      If the user already exists, then use the usermod command to modify it if necessary. If you cannot use the same user ID for the user on every node, then view the /etc/passwd file on all nodes to identify a user ID that is available on every node. You must then specify that ID for the user on all of the nodes.
  4. Set the password of the user. For example:

    # passwd oracle
    
  5. Complete SSH configuration for each user as described in the section "Configuring SSH or RCP on All Cluster Nodes".

  6. Complete user environment configuration tasks for each user as described in the section Configuring Software Owner User Environments.

3.3 Understanding the Oracle Base Directory Path

This section contains information about preparing an Oracle base directory.

3.3.1 Overview of the Oracle Base directory

During installation, you are prompted to specify an Oracle base location, which is owned by the user performing the installation. You can choose a location with an existing Oracle home, or choose another directory location that does not have the structure for an Oracle base directory. However, setting an Oracle base directory may become mandatory in a future release.

Using the Oracle base directory path helps to facilitate the organization of Oracle installations, and helps to ensure that installations of multiple databases maintain an Optimal Flexible Architecture (OFA) configuration.

3.3.2 Understanding Oracle Base and Oracle Clusterware Directories

Even if you do not use the same software owner to install Oracle Clusterware and Oracle Database, be aware that the root.sh script in the clusterware installation changes ownership of the Oracle Clusterware home directory to root. For this reason, the Oracle Clusterware home cannot be in the same location as other Oracle software.

3.4 Creating the Oracle Base Directory Path

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 u0[1-9]/app, and it must be writable by any member of the oinstall group.

Oracle recommends that you create an Oracle base path manually. The Optimal Flexible Architecture path for the Oracle Base is /u01/app/user, where user is the name of the user account that you want to own the Oracle Database software. For example:

# mkdir -p  /u01/app/oracle
# chown -R oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/app/oracle

3.5 Environment Requirements for Oracle Database and Oracle ASM Owners

If you create separate Oracle installation owner accounts for the database or ASM, then complete the following tasks for the Oracle Database software owner (oracle) and Oracle ASM software owner (asm).

  • If you create an Oracle base path, as described in the preceding section, then set the path to the Oracle base directory as an environment variable for the Oracle database owner. For example:

    # ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
    
  • Set the installation software owner user (asm, oracle) default file mode creation mask (umask) to 022 in the shell startup file. Setting the mask to 022 ensures that the user performing the software installation creates files with 644 permissions.

  • Set the software owners' environment variable DISPLAY environment variables in preparation for the ASM or Oracle Database installation