8 Oracle Grid Infrastructure Postinstallation Procedures

8.2.1 Configuring IPMI-based Failure Isolation Using Crsctl

On HP-UX platforms, where Oracle does not currently support the native IPMI driver, DHCP addressing is not supported and manual configuration is required for IPMI support. OUI will not collect the administrator credentials, the BMC must be configured with a static IP address, and the address must be manually stored in the OLR.

To configure Failure Isolation using IPMI, complete the following steps on each cluster member node:

1. If necessary, start Oracle Clusterware using the following command:

   $ crsctl start crs
   

2. Use the BMC management utility to obtain the BMC's IP address and then use the cluster control utility crsctl to store the BMC's IP address in the Oracle Local Registry (OLR) by issuing the crsctl set css ipmiaddr address command. For example:

   $ crsctl set css ipmiaddr 192.168.10.45
   

3. Enter the following crsctl command to store the user ID and password for the resident BMC in the OLR, where the noname user is the IPMI administrator user account, and provide the password when prompted:

   $ crsctl set css ipmiadmin ""
   IPMI BMC Password: 
   

   This command attempts to validate the credentials you enter by sending them to another cluster node. The command fails if that cluster node is unable to access the local BMC using the credentials.

   When you store the IPMI credentials in the OLR, you must have the anonymous user specified explicitly, or a parsing error will be reported.

8.2.2 Tuning Semaphore Parameters

Refer to the following guidelines only if the default semaphore parameter values are too low to accommodate all Oracle processes:

1. Calculate the minimum total semaphore requirements using the following formula:

   2 * sum (process parameters of all database instances on the system) + overhead for background processes + system and other application requirements

2. Set semmns (total semaphores systemwide) to this total.

3. Set semmsl (semaphores for each set) to 250.

4. Set semmni (total semaphores sets) to semmns divided by semmsl, rounded up to the nearest multiple of 1024.

8.2.3 Create a Fast Recovery Area Disk Group

During installation, by default you can create one disk group. If you plan to add an Oracle Database for a standalone server or an Oracle RAC database, then you should create the Fast Recovery Area for database files.

8.2.4 Checking the SCAN Configuration

The Single Client Access Name (SCAN) is a name that is used to provide service access for clients to the cluster. Because the SCAN is associated with the cluster as a whole, rather than to a particular node, the SCAN makes it possible to add or remove nodes from the cluster without needing to reconfigure clients. It also adds location independence for the databases, so that client configuration does not have to depend on which nodes are running a particular database instance. Clients can continue to access the cluster in the same way as with previous releases, but Oracle recommends that clients accessing the cluster use the SCAN.

You can use the command cluvfy comp scan (located in Grid home/bin) to confirm that the DNS is correctly associating the SCAN with the addresses. For example:

$ cluvfy comp scan 


Verifying scan

Checking Single Client Access Name (SCAN)...

Checking TCP connectivity to SCAN Listeners...
TCP connectivity to SCAN Listeners exists on all cluster nodes

Checking name resolution setup for ”node1.example.com”...

Verification of SCAN VIP and Listener setup passed

Verification of scan was successful.

After installation, when a client sends a request to the cluster, the Oracle Clusterware SCAN listeners redirect client requests to servers in the cluster.

8.2.5 Running Oracle RAC Configuration Audit Tool

Oracle recommends that you run the Oracle RAC configuration audit tool (ORAchk) to check your Oracle RAC installation. ORAchk is an Oracle RAC auditing tool that checks various important configuration settings within Oracle Real Application Clusters, Oracle Clusterware, Oracle Automatic Storage Management and the Oracle Grid Infrastructure environment.

For information about configuring and running ORAchk utility, refer to My Oracle Support note 1268927.1, which is available at the following URL:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.1

8.2.6 Setting Resource Limits for Oracle Clusterware and Associated Databases and Applications

After you have completed Oracle Grid Infrastructure installation, you can set resource limits in the Grid_home/crs/install/s_crsconfig_nodename_env.txt file. These resource limits apply to all Oracle Clusterware processes and Oracle databases managed by Oracle Clusterware. For example, to set a higher number of processes limit, edit the file and set CRS_LIMIT_NPROC parameter to a high value.

8.3.1 General Restrictions for Using Earlier Oracle Database Versions

You can use Oracle Database 10g Release 2 and Oracle Database 11g Release 1 and 2 with Oracle Clusterware 12c Release 1 (12.1).

Do not use the versions of srvctl, lsnrctl, or other Oracle Grid infrastructure home tools to administer earlier version databases. Only administer earlier Oracle Database releases using the tools in the earlier Oracle Database homes. To ensure that the versions of the tools you are using are the correct tools for those earlier release databases, run the tools from the Oracle home of the database or object you are managing.

If you upgrade an existing version of Oracle Clusterware and Oracle ASM to Oracle Grid Infrastructure 11g or later (which includes Oracle Clusterware and Oracle ASM), and you also plan to upgrade your Oracle RAC database to 12c Release 1 (12.1), then the required configuration of existing databases is completed automatically when you complete the Oracle RAC upgrade, and this section does not concern you.

8.3.2 Managing Server Pools with Earlier Database Versions

Starting with Oracle Grid Infrastructure 12c, Oracle Database server categories include roles such as Hub and Leaf that were not present in earlier releases. For this reason, you cannot create server pools using the Oracle RAC 11g version of Database Configuration Assistant (DBCA). To create server pools for earlier release Oracle RAC installations, use the following procedure:

1. Log in as the Oracle Grid Infrastructure installation owner (Grid user)

2. Change directory to the 12.1 Oracle Grid Infrastructure binaries directory in the Grid home. For example:

   # cd /u01/app/12.1.0/grid/bin
   

3. Use the Oracle Grid Infrastructure 12c version of srvctl to create a server pool consisting of Hub Node roles. For example, to create a server pool called p_hub with a maximum size of one cluster node, enter the following command:

   srvctl add serverpool -serverpool p_hub -min 0 -max 1 -category hub;
   

4. Log in as the Oracle RAC installation owner, start DBCA from the Oracle RAC Oracle home. For example:

   $ cd /u01/app/oracle/product/11.2.0/dbhome_1/bin
   $ dbca
   

   DBCA discovers the server pool that you created with the Oracle Grid Infrastructure 12c srvctl command. Configure the server pool as required for your services.

8.3.3 Using ASMCA to Administer Disk Groups for Earlier Database Versions

Use Oracle ASM Configuration Assistant (ASMCA) to create and modify disk groups when you install earlier Oracle databases and Oracle RAC databases on Oracle Grid Infrastructure installations. Starting with Oracle Database 11g Release 2 (11.2), Oracle ASM is installed as part of an Oracle Grid Infrastructure installation, with Oracle Clusterware. You can no longer use Database Configuration Assistant (DBCA) to perform administrative tasks on Oracle ASM.

8.3.4 Pinning Cluster Nodes for Oracle Database Release 10.x or 11.x

When Oracle Clusterware 12c Release 1 (12.1) is installed on a cluster with no previous Oracle software version, it configures the cluster nodes dynamically, which is compatible with Oracle Database Release 11.2 and later, but Oracle Database 10g and 11.1 require a persistent configuration. This process of association of a node name with a node number is called pinning.

To pin a node in preparation for installing or using an earlier Oracle Database version, use Grid_home/bin/crsctl with the following command syntax, where nodes is a space-delimited list of one or more nodes in the cluster whose configuration you want to pin:

crsctl pin css -n nodes

For example, to pin nodes node3 and node4, log in as root and enter the following command:

$ crsctl pin css -n node3 node4

To determine if a node is in a pinned or unpinned state, use Grid_home/bin/olsnodes with the following command syntax:

To list all pinned nodes:

olsnodes -t -n 

For example:

# /u01/app/12.1.0/grid/bin/olsnodes -t -n
node1 1       Pinned
node2 2       Pinned
node3 3       Pinned
node4 4       Pinned

To list the state of a particular node:

olsnodes -t -n node3

For example:

# /u01/app/12.1.0/grid/bin/olsnodes -t -n node3
node3 3       Pinned

8.3.5 Using the Correct LSNRCTL Commands

To administer local and SCAN listeners using the lsnrctl command, set your $ORACLE_HOME environment variable to the path for the Oracle Grid Infrastructure home (Grid home). Do not attempt to use the lsnrctl commands from Oracle home locations for previous releases, as they cannot be used with the new release.