2 Oracle Clusterware Preinstallation Tasks

This chapter describes the system configuration tasks that you must complete before you start Oracle Universal Installer (OUI) to install Oracle Clusterware.

This chapter contains the following topics:

2.1 Reviewing Upgrade Best Practices

If you have an existing Oracle installation, then document version numbers, patches, and other configuration information, and review upgrade procedures for your existing installation. Review Oracle upgrade documentation before proceeding with installation, to decide how you want to proceed.

For late-breaking updates and best practices about preupgrade, post-upgrade, compatibility, and interoperability discussions, refer to "Oracle Upgrade Companion." "Oracle Upgrade Companion" is available through Note 466181.1 on OracleMetaLink:

https://metalink.oracle.com

2.2 Logging In to a Remote System as root Using X Terminal

Before you install the Oracle software, you must complete several tasks as the root user on the system where you install Oracle software. To complete tasks as the root user on a remote server, enable remote display as root.

Note:

If you log in as another user (for example, oracle), then repeat this procedure for that user as well.

To enable remote display, complete one of the following procedures:

  • If you are installing the software from an X Window System workstation or X terminal, then:

    1. Start a local terminal session, for example, an X terminal (xterm).

    2. If you are not installing the software on the local system, then enter a command using the following syntax to enable remote hosts to display X applications on the local X server:

      $ xhost + remote_host
      

      where remote_host is the fully qualified remote hostname. For example:

      $ xhost + somehost.example.com
      somehost.example.com being added to the access control list
      
    3. If you are not installing the software on the local system, then use the ssh, command to connect to the system where you want to install the software:

      $ ssh remote_host
      

      where remote_host is the fully qualified remote hostname. For example:

      $ ssh somehost.example.com
      
    4. If you are not logged in as the root user, then enter the following command to switch the user to root:

      $ su - root
      password:
      #
      
  • If you are installing the software from a PC or other system with X server software installed, then:

    Note:

    If necessary, refer to your X server documentation for more information about completing this procedure. Depending on the X server software that you are using, you may need to complete the tasks in a different order.
    1. Start the X server software.

    2. Configure the security settings of the X server software to permit remote hosts to display X applications on the local system.

    3. Connect to the remote system where you want to install the software and start a terminal session on that system, for example, an X terminal (xterm).

    4. If you are not logged in as the root user on the remote system, then enter the following command to switch user to root:

      $ su - root
      password:
      #
      

2.3 Overview of Groups and Users for Oracle Clusterware Installations

You must create the following group and user to install Oracle Clusterware:

  • The Oracle Inventory group (typically, oinstall)

    You must create this group the first time that you install Oracle software on the system. In Oracle documentation, this group is referred to as oinstall.

    Note:

    If Oracle software is already installed on the system, then the existing Oracle Inventory group must be the primary group of the operating system user (oracle or crs) that you use to install Oracle Clusterware. Refer to "Determining If the Oracle Inventory and Oracle Inventory Group Exists" to identify an existing Oracle Inventory group.
  • Oracle clusterware software owner user (typically, oracle, if you intend to create a single software owner user for all Oracle software, or crs, if you intend to create separate Oracle software owners.)

    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.

    On HP-UX, the owner of Oracle Clusterware software must have the RTPRIO, MLOCK, and RTSCHED privileges.

See Also:

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

2.4 Creating Groups and Users for Oracle Clusterware

Log in as root, and use the following instructions to locate or create the Oracle Inventory group and a software owner for Oracle Clusterware:

2.4.1 Understanding the Oracle Inventory Group

You must have a group whose members are given access to write to the Oracle Central Inventory (oraInventory). The Central Inventory contains the following:

  • A registry of the Oracle home directories (Oracle Clusterware, Oracle Database, and Automatic Storage Management) on the system

  • Installation logs and trace files from installations of Oracle software. These files are also copied to the respective Oracle homes for future reference

Other metadata inventory information regarding Oracle installations are stored in the individual Oracle home inventory directories, and are separate from the Central Inventory.

2.4.2 Understanding the Oracle Inventory Directory

The first time you install Oracle software on a system, Oracle Universal Installer checks to see if you have created an Optimal Flexible Architecture (OFA) compliant path in the format u[01-09]/app, such as /u01/app, and that the user running the installation has permissions to write to that path. If this is true, then Oracle Universal Installer creates the Oracle Inventory directory in the path /u[01-09]/app/oraInventory. For example:

/u01/app/oraInventory

If you have set the environment variable $ORACLE_BASE for the user performing the Oracle Clusterware installation, then OUI creates the Oracle Inventory directory in the path $ORACLE_BASE/../oraInventory. For example, if $ORACLE_BASE is set to /opt/oracle/11, then the Oracle Inventory directory is created in the path /opt/oracle/oraInventory.

If you have created neither an OFA-compliant path nor set $ORACLE_BASE, then the Oracle Inventory directory is placed in the home directory of the user that is performing the installation. For example:

/home/oracle/oraInventory

As this placement can cause permission errors during subsequent installations with multiple Oracle software owners, Oracle recommends that you either create an OFA-compliant installation path, or set an $ORACLE_BASE environment path.

For new installations, Oracle recommends that you allow OUI to create the Central Inventory directory. By default, if you create an Oracle path in compliance with OFA structure, such as /u01/app, that is owned by an Oracle software owner, then the Central Inventory is created in the path u01/app/oraInventory using correct permissions to allow all Oracle installation owners to write to this directory.

2.4.3 Determining If the Oracle Inventory and Oracle Inventory Group Exists

When you install Oracle software on the system for the first time, OUI creates the oraInst.loc file. This file identifies the name of the Oracle Inventory group (typically, oinstall), and the path of the Oracle Central Inventory directory. An oraInst.loc file has contents similar to the following:

inventory_loc=central_inventory_location
inst_group=group

In the preceding example, central_inventory_location is the location of the Oracle Central Inventory, and group is the name of the group that has permissions to write to the central inventory.

If you have an existing Oracle Inventory, then ensure that you use the same Oracle Inventory for all Oracle software installations, and ensure that all Oracle software users you intend to use for installation have permissions to write to this directory.

To determine if you have an Oracle Inventory on your system:

  1. Enter the following command:

    # more /var/opt/oracle/oraInst.loc
    

    If the oraInst.loc file exists, then the output from this command is similar to the following:

    inventory_loc=/u01/app/oracle/oraInventory
    inst_group=oinstall
    

    In the previous output example:

    • The inventory_loc group shows the location of the Oracle Inventory

    • The inst_group parameter shows the name of the Oracle Inventory group (in this example, oinstall).

  2. Ensure that Oracle Inventory group members are granted the HP-UX privileges RTPRIO, MLOCK, and RTSCHED. For example:

    # /usr/bin/getprivgrp oinstall
    oinstall: RTPRIO MLOCK RTSCHED
    

    If the group is not granted these privileges, then add these privileges as described in the next section.

2.4.4 Creating the Oracle Inventory Group If an Oracle Inventory Does Not Exist

If the oraInst.loc file does not exist, then complete the following tasks:

  1. Create the Oracle Inventory group by entering a command similar to the following:

    # /usr/sbin/groupadd -g 501 oinstall
    

    The preceding command creates the group oinstall, with the group ID number 501.

  2. If it does not already exist, create the /etc/privgroup file. Add a line similar to the following to grant Oracle installation owners the RTPRIO, MLOCK, and RTSCHED privileges:

    # oinstall RTPRIO MLOCK RTSCHED
    

    If /etc/privgroup exists, then add these privileges to the Oracle Inventory group. For example:

    # /usr/sbin/setprivgrp oinstall RTPRIO MLOCK RTSCHED
    

    Confirm the grant of privileges to the group. For example:

    # /usr/bin/getprivgrp oinstall
    oinstall: RTPRIO MLOCK RTSCHED
    
  3. Repeat this procedure on all of the other nodes in the cluster.

2.4.5 Creating the Oracle Clusterware User

You must create a software owner for Oracle Clusterware in the following circumstances:

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

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

    In Oracle documentation, a user created to own only Oracle Clusterware software installations is called the crs user. A user created to own either all Oracle installations, or only Oracle database installations, is called the oracle user.

Note:

If you intend to use multiple Oracle software owners for different Oracle Database homes, then Oracle recommends that you create a separate Oracle software owner for Oracle Clusterware, and install Oracle Clusterware using the Oracle Clusterware software owner.

If you want to create separate Oracle software owners (oracle, crs, asm) to create separate users and separate operating system privileges groups for different Oracle software installations, then note that each of these users must have the oinstall group as their primary group, and each user must share the same Oracle Central Inventory, to prevent corruption of the Central Inventory. Refer to "Creating Custom Configuration Groups and Users for Job Roles".

2.4.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 (oinstall).

2.4.5.2 Creating or Modifying an Oracle Software Owner User for Oracle Clusterware

If the Oracle software owner (oracle, crs) user does not exist, or if you require a new Oracle software owner user, then create it. The following procedure uses crs as the name of the Oracle software owner.

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

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

    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 user ID number of the user you create for Oracle Clusterware, as you require it later during preinstallation.

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

    Use the usermod command to change user id numbers and groups. For example, to modify user ID numbers for an existing oracle account as part of an Oracle Clusterware installation using oracle as the Oracle Clusterware owner, enter commands similar to the following:

    # id oracle
    uid=500(oracle) gid=500(oracle) groups=500(oracle)
    # /usr/sbin/usermod -u 500 -g 501 -G 500,502 oracle
    # id oracle
    uid=500(oracle) gid=501(oinstall) groups=501(oinstall),500(oracle),502(dba)
    
  2. Set the password of the user that will own Oracle Clusterware. For example:

    # passwd crs
    
  3. Repeat this procedure on all of the other nodes in the cluster.

2.4.6 Example of Creating the Oracle Clusterware User and OraInventory Path

The following is an example of how to create the Oracle Clusterware software owner (in this case, crs), and a path compliant with OFA structure with correct permissions for the oraInventory directory. This example also shows how to create separate Oracle Database and Oracle ASM homes with correct ownership and permissions:

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

At the end of this procedure, you will have the following:

  • /u01 owned by root.

  • /u01/app owned by crs:oinstall with 775 permissions. This ownership and permissions enables OUI to create the oraInventory directory, in the path /u01/app/oraInventory.

  • /u01/app/crs owned by crs:oinstall with 775 permissions. These permissions are required for installation, and are changed during the installation process.

  • /u01/app/oracle owned by oracle:oinstall with 775 permissions.

  • /u01/app/asm owned by asm:oinstall with 775 permissions.

2.5 Checking the Hardware Requirements

Each system must meet the following minimum hardware requirements:

  • At least 1 GB of physical RAM

  • Swap space equivalent to the multiple of the available RAM, as indicated in the following table:

    Available RAM Swap Space Required
    Between 1 GB and 2 GB 1.5 times the size of RAM
    Between 2 GB and 8 GB Equal to the size of RAM
    More than 8 GB .75 times the size of RAM

  • 400 MB of disk space in the /tmp directory

  • 2 GB of disk space for Oracle Clusterware files, in partitions on separate physical disks, assuming standard redundancy (2 Oracle Cluster Registry partitions and 3 voting disks)

  • 650 MB of disk space for the Oracle Clusterware home

  • If you intend to install Oracle Database, allocate 4 GB of disk space for the Oracle base

  • If you intend to install Oracle Database single instance, allocate between 1.5 and 3.5 GB of disk space for a preconfigured database that uses file system storage. Oracle RAC software only requires 3.2 GB, and Oracle RAC software with sample schemas requires 3.3 GB.

    Note:

    The disk space requirement for databases that use Automatic Storage Management or shard disk storage is described in Chapter 5.

    Additional disk space, either on a file system or in an Automatic Storage Management disk group, is required for the Fast recovery area if you choose to configure automated backups.

To ensure that each system meets these requirements, follow these steps:

  1. To determine the physical RAM size, enter the following command:

    On HP PA-RISC systems:

    # grep "Physical:" /var/adm/syslog/syslog.log
    

    On HP Itanium systems:

    # /usr/contrib/bin/machinfo  | grep -i Memory
    

    If the size of the physical RAM installed in the system is less than the required size, then you must install more memory before continuing.

  2. To determine the size of the configured swap space, enter the following command:

    # /usr/sbin/swapinfo -a
    

    If necessary, refer to your operating system documentation for information about how to configure additional swap space.

  3. To determine the amount of disk space available in the /tmp directory, enter the following command:

    • # bdf /tmp
      

    If there is less than 400 MB of disk space available in the /tmp directory, then complete one of the following steps:

    • Delete unnecessary files from the /tmp directory to make available the disk space required.

    • Set the TEMP and TMPDIR environment variables when setting the oracle user's environment (described later). This environment variables can be used to override /tmp.

    • Extend the file system that contains the /tmp directory. If necessary, contact your system administrator for information about extending file systems.

  4. To determine the amount of free disk space on the system, enter the following command:

    • # bdf -k
      

    The following table shows the approximate disk space requirements for software files for each installation type:

    Installation Type Requirement for Software Files (GB)
    Enterprise Edition 4
    Standard Edition 4
    Custom (maximum) 4

  5. To determine whether the system architecture can run the software, enter the following command:

    # /bin/getconf KERNEL_BITS
    

    Note:

    The expected output of this command is 64. If you do not see the expected output, then you cannot install the software on this system.

2.6 Checking the Network Requirements

Review the following sections to check that you have the networking hardware and internet protocol (IP) addresses required for an Oracle Real Application Clusters (Oracle RAC) installation:

Note:

For the most up-to-date information about supported network protocols and hardware for Oracle RAC installations, refer to the Certify pages on the OracleMetaLink Web site at the following URL:
https://metalink.oracle.com

2.6.1 Network Hardware Requirements

The following is a list of requirements for network configuration:

  • Each node must have at least two ports: one for the public network interface, and one for the private network interface (the interconnect).

    If you want to use more than one NIC for the public network or for the private network, then Oracle recommends that you use NIC bonding.

  • The public interface names associated with the network adapters for each network must be the same on all nodes, and the private interface names associated with the network adaptors should be the same on all nodes.

    For example: With a two-node cluster, you cannot configure network adapters on node1 with eth0 as the public interface, but on node2 have eth1 as the public interface. Public interface names must be the same, so you must configure eth0 as public on both nodes. You should configure the private interfaces on the same network adapters as well. If eth1 is the private interface for node1, then eth1 should be the private interface for node2.

  • For the public network, each network adapter must support TCP/IP.

  • For the private network, the interconnect must support the user datagram protocol (UDP) using high-speed network adapters and switches that support TCP/IP (Gigabit Ethernet or better required).

    Note:

    UDP is the default interconnect protocol for Oracle RAC, and TCP is the interconnect protocol for Oracle Clusterware. You must use a switch for the interconnect. Oracle recommends that you use a dedicated switch.

    Oracle does not support token-rings or crossover cables for the interconnect.

  • For the private network, the endpoints of all designated interconnect interfaces must be completely reachable on the network. There should be no node that is not connected to every private network interface. You can test whether an interconnect interface is reachable using a ping command.

2.6.2 IP Address Requirements

Before starting the installation, you must have the following IP addresses available for each node:

  • An IP address with an associated host name (or network name) registered in the DNS for the public interface. If you do not have an available DNS, then record the host name and IP address in the system hosts file, /etc/hosts.

  • One virtual IP (VIP) address with an associated host name registered in a DNS. If you do not have an available DNS, then record the host name and VIP address in the system hosts file, /etc/hosts. Select an address for your VIP that meets the following requirements:

    • The IP address and host name are currently unused (it can be registered in a DNS, but should not be accessible by a ping command)

    • The VIP is on the same subnet as your public interface

  • A private IP address with a host name for each private interface

    Oracle recommends that you use private network IP addresses for these interfaces (for example: 10.*.*.* or 192.168.*.*). You can use DNS servers, or the /etc/hosts file, or both to register the private IP address. Note that if you use DNS servers alone, and the public network becomes unreachable due to NIC or cable failure, then the private IP addresses can fail to resolve.

    For the private interconnects, because of Cache Fusion and other traffic between nodes, Oracle strongly recommends using a physically separate, private network. You should ensure that the private IP addresses are reachable only by the cluster member nodes.

    During installation, you are asked to identify the planned use for each network interface that OUI detects on your cluster node. You must identify each interface as a public or private interface, and you must use the same private interfaces for both Oracle Clusterware and Oracle RAC.

    You can bond separate interfaces to a common interface to provide redundancy, in case of a NIC failure, but Oracle recommends that you do not create separate interfaces for Oracle Clusterware and Oracle RAC. If you use more than one NIC for the private interconnect, then Oracle recommends that you use NIC bonding. Note that multiple private interfaces provide load balancing but not failover, unless bonded.

    For example, if you intend to use the interfaces eth2 and eth3 as interconnects, then before installation, you must configure eth2 and eth3 with the private interconnect addresses. If the private interconnect addresses are 10.10.1.1 for eth2 and 10.10.2.1 for eth3, then bond eth2 and eth3 to an interface, such as bond0, using a separate subnet such as 10.10.222.0. During installation, define the Oracle Clusterware private node names on 10.10.222.0, and then define 10.10.222.0 (and only that one) as a private interconnect. This ensures that Oracle Clusterware and Oracle RAC are using the same network.

    After installation, if you modify interconnects on Oracle RAC with the CLUSTER_INTERCONNECTS initialization parameter, then you must change it to a private IP address, on a subnet that is not used with a public IP address, nor marked as a public subnet by oifcfg. Oracle does not support changing the interconnect to an interface using a subnet that you have designated as a public subnet.

    See Also:

    Oracle Clusterware Administration and Deployment Guide for further information about setting up and using bonded multiple interfaces

    You should not use a firewall on the network with the private network IP addresses, as this can block interconnect traffic.

Before installation, check that the default gateway can be accessed by a ping command. To find the default gateway, use the route command, as described in your operating system's help utility. After installation, configure clients to use either the VIP address, or the host name associated with the VIP. If a node fails, then the node's virtual IP address fails over to another node.

For example, with a two node cluster where each node has one public and one private interface, you might have the configuration shown in the following table for your network interfaces, where the hosts file is /etc/hosts:

Node Host Name Type IP Address Registered In
node1 node1 Public 143.46.43.100 DNS (if available, else the hosts file)
node1 node1-vip Virtual 143.46.43.104 DNS (if available, else the hosts file)
node1 node1-priv Private 10.0.0.1 Hosts file
node2 node2 Public 143.46.43.101 DNS (if available, else the hosts file)
node2 node2-vip Virtual 143.46.43.105 DNS (if available, else the hosts file)
node2 node2-priv Private 10.0.0.2 Hosts file

To enable VIP failover, the configuration shown in the preceding table defines the public and VIP addresses of both nodes on the same subnet, 143.46.43.

Note:

All host names must conform to the RFC 952 standard, which permits alphanumeric characters. Host names using underscores ("_") are not allowed.

2.6.3 Node Time Requirements

Before starting the installation, ensure that each member node of the cluster is set as closely as possible to the same date and time. Oracle strongly recommends using the Network Time Protocol feature of most operating systems for this purpose, with all nodes using the same reference Network Time Protocol server.

2.6.4 Network Configuration Options

The precise configuration you choose for your network depends on the size and use of the cluster you want to configure, and the level of availability you require.

If certified Network-attached Storage (NAS) is used for Oracle RAC and this storage is connected through Ethernet-based networks, then you must have a third network interface for I/O. Failing to provide three separate interfaces in this case can cause performance and stability problems under load.

For high capacity clusters with a small number of multiprocessor servers, to ensure high availability, you may want to configure redundant network interfaces to prevent a NIC failure from reducing significantly the overall cluster capacity. If you are using network storage, and want to provide redundant network interfaces, then Oracle recommends that you provide six network interfaces: two for the public network interface, two for the private network interface, and two for the network storage.

2.6.5 Configuring the Network Requirements

To verify that each node meets the requirements, follow these steps:

  1. If necessary, install the network adapters for the public and private networks and configure them with either public or private IP addresses.

  2. If you are using a domain name server (DNS), then for each node, register the host names and IP addresses for the public network interfaces in the DNS.

  3. Even if you are using a DNS, Oracle recommends that you add lines to the /etc/hosts file on each node, specifying the private IP addresses and associated private host names. Oracle also recommends that you add public and virtual IP addresses. Configure the /etc/hosts file so that it is similar to as shown in the following example, with private interface eth1, and private hosts nodeint1 and nodeint2:, where xxx represents parts of a valid IP address.

    #eth0 - PUBLIC
    xxx.xxx.100.45   node1.example.com    node1
    xxx.xxx.100.46   node2.example.com    node2
     
    #eth1 - PRIVATE
    10.0.0.1      nodeint1.example.com    nodeint1
    10.0.0.2      nodeint2.example.com    nodeint2
     
    #VIPs
    xxx.xxx.100.47   pmvip1.example.com    nodevip1
    xxx.xxx.100.48   pmvip2.example.com    nodevip2
    
  4. To check network configuration, on each node, enter the following commands:

    # hostname
    # /usr/sbin/ifconfig interface_name
    
    

    You can also check with the following command:

    # usr/bin/netstat -in
    

    Ensure that each server is properly identified, and that the interface name and IP address for all network adapters that you want to specify as public or private network interfaces are properly configured. In addition, use the ping command to ensure that each node can obtain a response for the public and private IP addresses from each other node in the cluster.

    Note:

    When you install Oracle Clusterware and Oracle RAC, you will require the public, private and virtual IP addresses. Make a note of the addresses you configured in the /etc/hosts file or DNS.

2.6.6 Configuring the Name Service Switch to Tolerate Public Network Failures

On HP-UX, to tolerate a complete public network failure, you should specify network addresses in /etc/nsswitch.conf, to avoid VIP failover or public address network failure response times being dependent on the network timeouts.

In the /etc/nsswitch.conf file, files must precede other entries for host, and preferably precede other entries in nsswitch.conf.

2.7 Identifying Software Requirements

Depending on the products that you intend to install, verify that the following software is installed on the system. The procedure following the table describes how to check these requirements.

Note:

Oracle Universal Installer performs checks on your system to verify that it meets the listed requirements. To ensure that these checks pass, verify the requirements before you start Oracle Universal Installer.

The parameters in the following table are minimum patch revisions required for installation; later patch revisions are not tested, but are expected to work.

The following is the list of supported HP-UX platforms and requirements at the time of release:

2.7.1 Software Requirements List for HP-UX PA-RISC (64-Bit) Platforms

Table 2-1 HP-UX PA-RISC (64-Bit) Requirements

Item Requirement

Operating system

Operating system versions:

  • HP-UX 11i Version 3 (11.31) PA-RISC

  • HP-UX 11i Version 2 (11.23) PA-RISC Sept 2004 base or later, with March 2007 Patch bundle for HP-UX (11iV2- B.11.23.0703)

HP-UX 11.31 packages and bundles

PHKL_35900 (operating system patch)

PHKL_35936 (operating system patch)

PHKL_36248 (operating system patch)

PHKL_36249 (operating system patch)

HP-UX 11.23 packages and bundles

PHKL_35478: s700_800 11.23 shmget(2) cumulative patch

PHKL_36853: s700_800 11.23 pstat patch

PHCO_36673: s700_800 11.23 libc cumulative patch

Oracle Clusterware

All HP-UX 11.31 installations

No additional requirements for Oracle Clusterware.

At the time of this release, Hyper Messaging Protocol (HMP) is not supported.

Only HP Serviceguard A11.17.01 is supported with Oracle Clusterware 11g.

Note: HP Serviceguard is optional. It is required only if you want to use shared logical volumes for Oracle Clusterware or database files.

All HP-UX 11.23 installations

At the time of this release, Hyper Messaging Protocol (HMP) is not supported.

HP Serviceguard A11.17.00 with patch PHSS_35371 or later is supported with Oracle Clusterware 11g.

Note: HP Serviceguard is optional. It is required only if you want to use shared logical volumes for Oracle Clusterware or database files.

Oracle JDBC/OCI Drivers

  • Java SDK 5.0

Note: HP JDK 1.5.0.06 is installed with this release.

Oracle Messaging Gateway

  • WebSphere MQ (Server) v. 6.0

  • WebSphere MQ (Client) v. 6.0

Oracle Spatial

HP-UX Developer's Toolkit - X11 and lmake

Note: This software is required only to build the sample programs.

Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer's Kit (XDK)

HP-UX 11.31

  • HP C/aC++ A.03.74 (Swlist Bundle - C.11.31.01) - February 2007 A.03.74

  • HP C/aC++ B.11.31.01 (Swlist Bundle - C.11.31.01) - February 2007 B.11.31.01

HP-UX 11.23

  • HP/ANSI C compiler (B.11.11.16) - June 2006 (AR0606) - release B.11.11.16:

    C-ANSI-C

  • Install the following patches for HP C/ANSI C Compiler:

    PHSS_35101 (C Compiler patch)

    PHSS_35103 (C Compiler +O4/PBO Compiler B.11.11.16 cumulative patch)

    PHSS_35176 (C Compiler patch)

  • C++ (aCC) Compiler (A.03.70) -- June 2006 (AR0606) - release A.03.70:

    ACXX

  • Install the following patches for HP C/ANSI C Compiler:

    PHSS_35102 (This changes the C++ Compiler version from A.03.70 to 03.73)

    PHSS_35103 (C Compiler +O4/PBO Compiler B.11.11.16 cumulative patch)

Pro*COBOL

Accucobol 6.1

Pro*FORTRAN

HP-UX 11.31:

HP FORTRAN/90 (Feb 2007 - release)

HP-UX 11.23:

HP FORTRAN 90 (June 2006 - AR0606)


2.7.2 Software Requirements List for HP-UX Itanium Platforms

Table 2-2 HP-UX Itanium Requirements

Item Requirement

Operating system

  • HP-UX 11i Version 3 (11.31) with March 2007 Patch bundle for HP-UX (11iV2-B.11.23.0703)

  • HP-UX 11i Version 2 (11.23) with Sept 04 or newer base)

HP-UX 11.31 packages and bundles

PHKL_35900 (operating system patch)

PHKL_35936 (operating system patch)

PHKL_36248 (operating system patch)

PHKL_36249 (operating system patch)

HP-UX 11.23 packages and bundles

PHCO_36673: s700_800 11.23 libc cumulative patch

PHKL_35478 (s700_800 11.23 shmget(2) cumulative patch)

PHKL 36853 (s700_800 11.23 pstat patch)

Oracle JDBC/OCI Drivers

  • Java SDK 5.0

Note: HP JDK 1.5.0.06 is installed with this release.

Oracle Spatial

HP-UX Developer's Toolkit - X11 and Imake

Note: This software is required only to build the sample programs.

Pro*COBOL complier

Micro Focus Server Express 5.0

Pro*Fortran compiler

HP-UX 11.31:

HP FORTRAN/90 - Feb 2007 - release

HP-UX 11.23:

HP FORTRAN 90 June 2006 (AR0606) - release B11.23.20

Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer's Kit (XDK)

  • HP-UX 11.31

    A.06.15 (September 2007 Application Release CD, swlist bundle C.11.31.03)

  • HP-UX 11.23

    HP aC++ Compiler C++ (aCC) Compiler (September 2008 Application Release CD, swlist bundle C.11.23.15

    HP ANSI C compiler (C.06.10) - June 2006 (AR0606) - release C.06.10

    C++ patches

    PHSS_33279 (s700_800 11.23 u2comp/be/plugin library patch)

    PHSS_34650

    C patches

    PHSS_35974 (Updates C Compiler to (A.06.14)

    PHSS_33279 (s700_800 11.23 u2comp/be/plugin library patch)

    PHSS_35975 (Updates C++ Compiler to (A.06.13))

Oracle Clusterware

All HP-UX 11.31 installations

No additional requirements for Oracle Clusterware.

At the time of this release, Hyper Messaging Protocol (HMP) is not supported.

Only HP Serviceguard A11.17.01 is supported with Oracle Clusterware 11g.

Note: HP Serviceguard is optional. It is required only if you want to use shared logical volumes for Oracle Clusterware or database files.

All HP-UX 11.23 installations

PHKL_34941 (Improves Oracle Clusterware restart and diagnosis)

No additional requirements for Oracle Clusterware.

At the time of this release, Hyper Messaging Protocol (HMP) is not supported.

HP Serviceguard A11.17.00 with patch PHSS_35371 or later is supported with Oracle Clusterware 11g.

Note: HP Serviceguard is optional. It is required only if you want to use shared logical volumes for Oracle Clusterware or database files.


2.8 Checking the Software Requirements

To ensure that the system meets these requirements, follow these steps:

  1. To determine which version of HP-UX is installed, enter the following command:

    # uname -a
    HP-UX hostname B.11.23 U 9000/800 109444686 unlimited-user license
    

    In this example, the version of HP-UX 11i is 11.23.

  2. To determine whether a bundle, product, or fileset is installed, enter a command similar to the following, where level is bundle, product, or fileset:

    # /usr/sbin/swlist -l level | more
    

    If a required bundle, product, or fileset is not installed, then you must install it. Refer to your operating system or software documentation for information about installing products.

  3. On PA-RISC systems only, enter the following command to determine if the HP-UX 11i Quality Pack is installed:

    # /usr/sbin/swlist -l bundle | grep -i Quality
    

    If the Quality Pack is not installed or if the date is before June 2003, then download the latest Quality Pack from the following Web site and install it:

    http://h20293.www2.hp.com/SUPPORT_PLUS/qpk.html?jumpid=reg_R1002_USEN
    
  4. To determine whether a patch is installed, enter a command similar to the following:

    # /usr/sbin/swlist -l patch | grep PHSS_28880
    

    Alternatively, to list all installed patches, enter the following command:

    # /usr/sbin/swlist -l patch | more
    

    If a required patch is not installed, then download it from the following Web site and install it:

    http://itresourcecenter.hp.com
    

    If the Web site shows a more recent version of the patch, then download and install that version.

  5. If you require a CSD for WebSphere MQ, then refer to the following Web site for download and installation information:

    http://www-306.ibm.com/software/
    

Note:

There may be more recent versions of the patches listed installed on the system. If a listed patch is not installed, then determine whether a more recent version is installed before installing the version listed.

2.9 Configuring Kernel Parameters

Note:

The kernel parameter values shown in this section are recommended values only. For production database systems, Oracle recommends that you tune these values to optimize the performance of the system. See your operating system documentation for more information about tuning kernel parameters.

On HP-UX 11.31 (version 3), the following parameters are not valid:

  • msgmap

  • ncallout

On all cluster nodes, verify that the kernel parameters shown in Table 2-3 are set either to the formula shown, or to values greater than or equal to the recommended value shown. The procedure following the table describes how to verify and set the values.

Table 2-3 Recommended HP-UX Kernel Parameter Values

Parameter Recommended Formula or Value

ksi_alloc_max

(nproc*8)

executable_stack

0

max_thread_proc

1024

maxdsiz

1073741824 (1 GB)

maxdsiz_64bit

2147483648 (2 GB)

maxssiz

134217728 (128 MB)

maxssiz_64bit

1073741824 (1 GB)

maxuprc

((nproc*9)/10)

msgmap

(msgtql+2)

msgmni

(nproc)

msgseg

32767

msgtql

(nproc)

ncsize

(ninode+1024)

nfile

(15*nproc+2048)

nflocks

(nproc)

ninode

(8*nproc+2048)

nkthread

(((nproc*7)/4)+16)

nproc

4096

semmni

(nproc)

semmns

(semmni*2)

semmnu

(nproc-4)

semvmx

32767

shmmax

The size of physical memory or 1073741824 (0X40000000), whichever is greater.

Note: To avoid performance degradation, the value should be greater than or equal to the size of the SGA.

shmmni

4096

shmseg

512

vps_ceiling

64


Note:

If the current value for any parameter is higher than the value listed in this table, then do not change the value of that parameter.

To view the current value or formula specified for these kernel parameters, and to change them if necessary, use System Administration Manager (SAM) or kctune. The following procedure describes how to modify kernel settings using SAM:

  1. Follow these steps, depending on your platform:

    PA-RISC:

    1. Optionally, set the DISPLAY environment variable to specify the display of the local system:

      • Bourne or Korn shell:

        # DISPLAY=local_host:0.0 ; export DISPLAY
        
      • C shell:

        # setenv DISPLAY local_host:0.0
        
    2. Start SAM:

      # /usr/sbin/sam
      
    3. Choose the Kernel Configuration area, then choose the Configurable Parameters area.

    4. Check the value or formula specified for each of these parameters and, if necessary, modify that value or formula.

      If necessary, refer to the SAM online Help for more information about completing this step.

      Note:

      If you modify the value of a parameter that is not dynamic, then you must restart the system.

    Itanium:

    1. Enter the following command to start the kcweb application:

      # /usr/sbin/kcweb -F
      
    2. Check the value or formula specified for each of these parameters and, if necessary, modify that value or formula.

      If necessary, refer to the kcweb online Help for more information about completing this step.

      Note:

      If you modify the value of a parameter that is not dynamic, then you must restart the system.
  2. If necessary, when the system restarts, log in and switch user to root.

  3. Complete this procedure on all other cluster nodes.

2.10 Configuring SSH or RCP on All Cluster Nodes

Before you install and use Oracle Real Application clusters, you must enable remote copy of files to cluster nodes during installation, and you must prevent errors that can result from scripts that affect remote file copies and commands.

You can configure secure shell (SSH) for Oracle software installation owners (crs, oracle, asm) on all cluster nodes. OUI then uses the ssh and scp commands during installation to run remote commands on and copy files to the other cluster nodes. If you want to use SSH, then you must configure SSH so that these commands do not prompt for a password.

If SSH is not available, then Oracle Universal Installer attempts to use remote copy (rcp) and remsh instead. You must enable RCP for root, and for Oracle software installation owners (crs, oracle, asm).

HP-UX Secure Shell is based on OpenSSH. If you encounter problems establishing user equivalency with your SSH distribution, then either use the HP-UX secure shell, or install OpenSSH, or enable rsh.

Refer to the following sections as needed:

2.10.1 Configuring RCP on Cluster Member Nodes

To enable remote copy:

  1. On each node in the cluster, using a text editor, create or open the .rhosts file in the root account home directory. Add lines similar to the following, where node1 and node2 are member nodes in the cluster, and domain is the domain name for the cluster:

    node1 root
    node1.domain root
    node2 root
    node2.domain root
    

    If you create the .rhosts file, then ensure that permissions for the .rhost file are set to 400. For example:

    # chmod 400 .rhosts
    
  2. For each Oracle installation owner account, open the .rhosts file in that user account home directory (in this example, crs). Add lines similar to the following, where node1 and node2 are member nodes in the cluster, and domain is the domain name for the cluster:

    node1 crs
    node1.domain crs
    node2 crs
    node2.domain crs
    

    If you create the .rhosts file, then ensure that permissions for the .rhost file are set to 400. For example:

    # chmod 400 .rhosts
    
  3. Test the RCP configuration for root and for Oracle installation owner accounts. For example:

    [root@node1] # remsh node2 11
    [root@node1] # remsh node1 11
    
    [root@node2] # remsh node1 11
    [root@node2} # remsh node2 11
    
    [crs@node1] $ remsh node2 11
    [crs@node1] $ remsh node1 11
    
    [crs@node2] $ remsh node1 11
    [crs@node2} $ remsh node2 11
    

2.10.2 Checking Existing SSH Configuration on the System

To determine if SSH is running, enter the following command:

$ ps -ef | grep sshd

If SSH is running, then the response to this command is one or more process ID numbers. In the home directory of the software owner that you want to use for the installation (crs, oracle), use the command ls -al to ensure that the .ssh directory is owned and writable only by the user.

You need either an RSA or a DSA key for the SSH protocol. RSA is used with the SSH 1.5 protocol, while DSA is the default for the SSH 2.0 protocol. With OpenSSH, you can use either RSA or DSA. The instructions that follow are for SSH1. If you have an SSH2 installation, and you cannot use SSH1, then refer to your SSH distribution documentation to configure SSH1 compatibility or to configure SSH2 with DSA.

2.10.3 Configuring SSH on Cluster Member Nodes

To configure SSH, you must first create RSA or DSA keys on each cluster node, and then copy all the keys generated on all cluster node members into an authorized keys file that is identical on each node. Note that the SSH files must be readable only by root and by the software installation user (oracle, crs, asm), as SSH ignores a private key file if it is accessible by others. When this is done, then start the SSH agent to load keys into memory. In the examples that follow, the RSA key is used.

You must configure SSH separately for each Oracle software installation owner that you intend to use for installation.

To configure SSH, complete the following:

2.10.3.1 Create .SSH, and Create RSA Keys On Each Node

Complete the following steps on each node:

  1. Log in as the software owner (in this example, the crs user).

  2. To ensure that you are logged in as the Oracle user, and that the user ID matches the expected user ID you have assigned to the Oracle user, enter the commands id and id crs. Ensure that Oracle user group and user and the terminal window process group and user IDs are identical. For example:

    $ id 
    uid=502(crs) gid=501(oinstall) groups=501(oinstall),502(crs)
    $ id crs
    uid=502(crs) gid=501(oinstall) groups=501(oinstall),502(crs)
    
  3. If necessary, create the .ssh directory in the crs user's home directory, and set permissions on it to ensure that only the oracle user has read and write permissions:

    $ mkdir ~/.ssh
    $ chmod 700 ~/.ssh
    
  4. Enter the following command:

    $ /usr/bin/ssh-keygen -t rsa
    

    At the prompts:

    • Accept the default location for the key file (press Enter).

    • Enter and confirm a pass phrase unique for this installation user.

    This command writes the RSA public key to the ~/.ssh/id_rsa.pub file and the private key to the ~/.ssh/id_rsa file.

    Never distribute the private key to anyone not authorized to perform Oracle software installations.

  5. Repeat steps 1 through 4 on each node that you intend to make a member of the cluster, using the RSA key.

2.10.3.2 Add All Keys to a Common authorized_keys File

Complete the following steps:

  1. On the local node, change directories to the .ssh directory in the Oracle Clusterware owner's home directory (typically, either crs or oracle).

    Then, add the RSA key to the authorized_keys file using the following commands:

    $ cat id_rsa.pub >> authorized_keys
    $ ls
    

    In the .ssh directory, you should see the id_rsa.pub keys that you have created, and the file authorized_keys.

  2. On the local node, use SCP (Secure Copy) or SFTP (Secure FTP) to copy the authorized_keys file to the oracle user .ssh directory on a remote node. The following example is with SCP, on a node called node2, with the Oracle Clusterware owner crs, where the crs user path is /home/crs:

    [crs@node1 .ssh]$ scp authorized_keys node2:/home/crs/.ssh/
    

    You are prompted to accept an RSA key. Enter Yes, and you see that the node you are copying to is added to the known_hosts file.

    When prompted, provide the password for the crs user, which should be the same on all nodes in the cluster. The authorized_keys file is copied to the remote node.

    Your output should be similar to the following, where xxx represents parts of a valid IP address:

    [crs@node1 .ssh]$ scp authorized_keys node2:/home/crs/.ssh/
    The authenticity of host 'node2 (xxx.xxx.173.152) can't be established.
    RSA key fingerprint is 7e:60:60:ae:40:40:d1:a6:f7:4e:zz:me:a7:48:ae:f6:7e.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'node1,xxx.xxx.173.152' (RSA) to the list
    of known hosts
    crs@node2's password:
    authorized_keys       100%             828             7.5MB/s      00:00
    
  3. Using SSH, log in to the node where you copied the authorized_keys file, using the pass phrase you created. Then change to the .ssh directory, and using the cat command, add the RSA keys for the second node to the authorized_keys file:

    [crs@node1 .ssh]$ ssh node2
    The authenticity of host node2 (xxx.xxx.100.102) can't be established. RSA key fingerprint is z3:z3:33:z3:z3:33:zz:76:z3:z3:z3.
    Are you sure you want to continue connecting? (yes/no)? yes
    Enter passphrase for key '/home/oracle/.ssh/id_rsa':
    [crs@node2 crs]$ cd .ssh
    [crs@node2 ssh]$ cat id_rsa.pub  >> authorized_keys
    

    Repeat steps 2 and 3 from each node to each other member node in the cluster.

    When you have added keys from each cluster node member to the authorized_keys file on the last node you want to have as a cluster node member, then use scp to copy the authorized_keys file with the keys from all nodes back to each cluster node member, overwriting the existing version on the other nodes.

    If you want to confirm that you have all nodes in the authorized_keys file, enter the command more authorized_keys, and check to see that there is an RSA key for each member node. The file lists the type of key (ssh-rsa), followed by the key, and then followed by the user and server. For example:

    ssh-rsa AAAABBBB . . . = crs@node1
    

    Note:

    The crs user's /.ssh/authorized_keys file on every node must contain the contents from all of the /.ssh/id_rsa.pub files that you generated on all cluster nodes.

2.10.4 Enabling SSH User Equivalency on Cluster Member Nodes

To enable Oracle Universal Installer to use the ssh and scp commands without being prompted for a pass phrase, follow these steps:

  1. On the system where you want to run Oracle Universal Installer, log in as the oracle user.

  2. Enter the following commands:

    $ exec /usr/bin/ssh-agent $SHELL
    $ /usr/bin/ssh-add
    
  3. At the prompts, enter the pass phrase for each key that you generated.

    If you have configured SSH correctly, then you can now use the ssh or scp commands without being prompted for a password or a pass phrase.

  4. If you are on a remote terminal, and the local node has only one visual (which is typical), then use the following syntax to set the DISPLAY environment variable:

    Bourne or Korn shell:

    $ export DISPLAY=hostname:0
    

    C shell:

    $ setenv DISPLAY hostname:0
    

    For example, if you are using the Bourne shell, and if your hostname is node1, then enter the following command:

    $ export DISPLAY=node1:0
    
  5. To test the SSH configuration, enter the following commands from the same terminal session, testing the configuration of each cluster node, where nodename1, nodename2, and so on, are the names of nodes in the cluster:

    $ ssh nodename1 date
    $ ssh nodename2 date
        .
        .
        .
    

    These commands should display the date set on each node.

    If any node prompts for a password or pass phrase, then verify that the ~/.ssh/authorized_keys file on that node contains the correct public keys.

    If you are using a remote client to connect to the local node, and you see a message similar to "Warning: No xauth data; using fake authentication data for X11 forwarding," then this means that your authorized keys file is configured correctly, but your ssh configuration has X11 forwarding enabled. To correct this issue, proceed to step 6.

    Note:

    The first time you use SSH to connect to a node from a particular system, you may see a message similar to the following:
    The authenticity of host 'node1 (140.87.152.153)' can't be established.
    RSA key fingerprint is 7z:ez:e7:f6:f4:f2:4f:8f:9z:79:85:62:20:90:92:z9.
    Are you sure you want to continue connecting (yes/no)? 
    

    Enter yes at the prompt to continue. You should not see this message again when you connect from this system to that node.

    If you see any other messages or text, apart from the date, then the installation can fail. Make any changes required to ensure that only the date is displayed when you enter these commands.

    You should ensure that any parts of login scripts that generate any output, or ask any questions, are modified so that they act only when the shell is an interactive shell.

  6. To ensure that X11 forwarding will not cause the installation to fail, create a user-level SSH client configuration file for the Oracle software owner user, as follows:

    1. Using any text editor, edit or create the ~oracle/.ssh/config file.

    2. Make sure that the ForwardX11 attribute is set to no. For example:

      Host *
            ForwardX11 no
      
  7. You must run Oracle Universal Installer from this session or remember to repeat steps 2 and 3 before you start Oracle Universal Installer from a different terminal session.

2.10.5 Setting Display and X11 Forwarding Configuration

  • If you are on a remote terminal, and the local node has only one visual (which is typical), then use the following syntax to set the DISPLAY environment variable:

    Bourne and Korn shells:

    $ export DISPLAY=hostname:0
    

    C shell:

    $ setenv DISPLAY hostname:0
    

    For example, if you are using the Bourne shell, and if your hostname is node1, then enter the following command:

    $ export DISPLAY=node1:0
    
  • To ensure that X11 forwarding will not cause the installation to fail, create a user-level SSH client configuration file for the Oracle software owner user, as follows:

    1. Using any text editor, edit or create the software installation owner's ~/.ssh/config file.

    2. Make sure that the ForwardX11 attribute is set to no. For example:

      Host *
            ForwardX11 no
      

2.10.6 Preventing Oracle Clusterware Installation Errors Caused by stty Commands

During an Oracle Clusterware installation, Oracle Universal Installer uses SSH (if available) to run commands and copy files to the other nodes. During the installation, hidden files on the system (for example, .cshrc) will cause makefile and other installation errors if they contain stty commands.

To avoid this problem, you must modify these files to suppress all output on STDERR, as in the following examples:

  • Bourne or Korn shell:

    if [ -t 0 ]; then
       stty intr ^C
    fi
    
  • C shell:

    test -t 0
    if ($status == 0) then
       stty intr ^C
    endif
    

    Note:

    When SSH is not available, the Installer uses the rsh and rcp commands instead of ssh and scp.

    If there are hidden files that contain stty commands that are loaded by the remote shell, then OUI indicates an error and stops the installation.

2.11 Configuring Software Owner User Environments

You run OUI from the user account that you want to own the Oracle Clusterware installation (oracle or crs). However, before you start OUI you must configure the environment of the user performing the Oracle Clusterware installation. In addition, create other required Oracle software owners, if needed.

To set the Oracle software owners' environments, follow these steps, for each software owner (crs, oracle, asm):

  1. Start a new terminal session; for example, start an X terminal (xterm).

  2. Enter the following command to ensure that X Window applications can display on this system:

    $ xhost + hostname
    

    The hostname is the name of the local host.

  3. If you are not already logged in to the system where you want to install the software, then log in to that system as the software owner user.

  4. If you are not logged in as the user, then switch to the software owner user you are configuring. For example, with the crs user:

    $ su - crs
    
  5. To determine the default shell for the user, enter the following command:

    $ echo $SHELL
    
  6. Open the user's shell startup file in any text editor:

    • Bourne shell (sh) or Korn shell (ksh):

      $ vi .profile
      
    • C shell (csh or tcsh):

      % vi .login
      
  7. If the ORACLE_SID, ORACLE_HOME, or ORACLE_BASE environment variable is set in the file, then remove the appropriate lines from the file.

  8. Save the file, and exit from the text editor.

  9. To run the shell startup script, enter one of the following commands:

    • Bourne or Korn shell:

      $ . ./.profile
      
    • C shell:

      % source ./.login
      
  10. If you are not installing the software on the local system, then enter a command similar to the following to direct X applications to display on the local system:

    • Bourne or Korn shell:

      $ DISPLAY=local_host:0.0 ; export DISPLAY
      
    • C shell:

      % setenv DISPLAY local_host:0.0
      

    In this example, local_host is the host name or IP address of the system that you want to use to display OUI (your workstation or PC).

  11. If you determined that the /tmp directory has less than 400 MB of free disk space, then identify a file system with at least 400 MB of free space and set the TEMP and TMPDIR environment variables to specify a temporary directory on this file system:

    Note:

    You cannot use a shared file system as the location of the temporary file directory (typically /tmp) for Oracle RAC installation. If you place /tmp on a shared file system, then the installation fails.
    1. Use the bdf command to identify a suitable file system with sufficient free space.

    2. If necessary, enter commands similar to the following to create a temporary directory on the file system that you identified, and set the appropriate permissions on the directory:

      $ su - root
      # mkdir /mount_point/tmp
      # chmod a+wr /mount_point/tmp
      # exit
      
    3. Enter commands similar to the following to set the TEMP and TMPDIR environment variables:

      • Bourne or Korn shell:

        $ TEMP=/mount_point/tmp
        $ TMPDIR=/mount_point/tmp
        $ export TEMP TMPDIR
        
      • C shell:

        % setenv TEMP /mount_point/tmp
        % setenv TMPDIR /mount_point/tmp
        
  12. If you plan to use raw devices for database file storage, then set the DBCA_RAW_CONFIG environment variable to specify the full path to the raw device mapping file:

    • Bourne or Korn shell:

      $ DBCA_RAW_CONFIG=$ORACLE_BASE/oradata/dbname/dbname_raw.conf
      $ export DBCA_RAW_CONFIG
      
    • C shell:

      % setenv DBCA_RAW_CONFIG=$ORACLE_BASE/oradata/dbname/dbname_raw.conf
      
  13. Enter the following command to ensure that the ORACLE_HOME and TNS_ADMIN environment variables are not set:

    • Bourne or Korn shell:

      $ unset ORACLE_HOME
      $ unset TNS_ADMIN
      
    • C shell:

      % unsetenv ORACLE_HOME
      % unsetenv TNS_ADMIN
      

    Note:

    If the ORACLE_HOME environment variable is set, the Installer uses the value that it specifies as the default path for the Oracle home directory. However, if you set the ORACLE_BASE environment variable, Oracle recommends that you unset the ORACLE_HOME environment variable and choose the default path suggested by the Installer.

2.12 Creating Required Symbolic Links

Note:

This task is required only if the Motif 2.1 Development Environment package (X11MotifDevKit.MOTIF21-PRG) is not installed.

To enable you to successfully relink Oracle products after installing this software, enter the following commands to create required X library symbolic links in the /usr/lib directory:

# cd /usr/lib
# ln -s libX11.3 libX11.sl
# ln -s libXIE.2 libXIE.sl
# ln -s libXext.3 libXext.sl
# ln -s libXhp11.3 libXhp11.sl
# ln -s libXi.3 libXi.sl
# ln -s libXm.4 libXm.sl
# ln -s libXp.2 libXp.sl
# ln -s libXt.3 libXt.sl
# ln -s libXtst.2 libXtst.sl

2.13 Requirements for Creating an Oracle Clusterware Home Directory

During installation, you are prompted to provide a path to a home directory to store Oracle Clusterware binaries. Ensure that the directory path you provide meets the following requirements:

  • It should be created in a path separate from existing Oracle homes.

  • It should not be located in a user home directory.

  • It should be created either as a subdirectory in a path where all files can be owned by root, or in a unique path.

  • Before installation, it should be owned by the installation owner of Oracle Clusterware (typically oracle for a single installation owner for all Oracle software, or crs for role-based Oracle installation owners), and set to 750 permissions.

For installations with Oracle Clusterware only, Oracle recommends that you create a path compliant with Oracle Optimal Flexible Architecture (OFA) guidelines, so that Oracle Universal Installer (OUI) can select that directory during installation. For OUI to recognize the path as an Oracle software path, it must be in the form u0[1-9]/app.

When OUI finds an OFA-compliant path, it creates the Oracle Clusterware and Oracle Central Inventory (oraInventory) directories for you.

Create an Oracle Clusterware path. For example:

# mkdir -p  /u01/app
# chown -R crs:oinstall /u01

Alternatively, if you later intend to install Oracle Database software, then create an Oracle base path. OUI automatically creates an OFA-compliant path for Oracle Clusterware derived from the Oracle base path. 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

Note:

If you choose to create an Oracle Clusterware home manually, then do not create the Oracle Clusterware home under Oracle base. Creating an Oracle Clusterware installation in an Oracle base directory will cause succeeding Oracle installations to fail.

See Also:

"Creating Standard Configuration Operating System Groups and Users", and "Creating Custom Configuration Groups and Users for Job Roles" for information about creating groups, users, and software homes for additional Oracle software installations

2.14 Understanding and Using Cluster Verification Utility

Cluster Verification Utility (CVU) is a tool that performs system checks. This guide provides Cluster Verification Utility commands to assist you with confirming that your system is properly configured for Oracle Clusterware and Oracle RAC installation.

This section describes the following topics:

2.14.1 Entering Cluster Verification Utility Commands

Cluster Verification Utility is provided with two scripts: runcluvfy.sh, which is designed to be used before installation, and cluvfy, which is in the path CRS_home/bin. The script runcluvfy.sh contains temporary variable definitions which enable it to be run before installing Oracle Clusterware or Oracle Database. After you install Oracle Clusterware, use the command cluvfy to check prerequisites and perform other system readiness checks.

Before Oracle software is installed, to enter a Cluster Verification Utility command, change directories and start runcluvfy.sh using the following syntax:

cd /mountpoint
./runcluvfy.sh options

In the preceding example, the variable mountpoint represents the mountpoint path for the installation media and the variable options represents the Cluster Verification Utility command options that you select. For example:

$ cd /mnt/dvdrom
$ ./runcluvfy.sh comp nodereach -n node1,node2 -verbose

By default, when you enter a Cluster Verification Utility command, the utility provides a summary of the test. During preinstallation, Oracle recommends that you obtain detailed output by using the -verbose argument with the command. The -verbose argument produces detailed output of individual checks. Where applicable, it shows results for each node in a tabular layout.

2.14.2 Using CVU to Determine if Installation Prerequisites are Complete

You can use Cluster Verification Utility (CVU) to determine which system prerequisites for installation are already completed. Use this option if you are installing Oracle 11g release 1 (11.1) on a system with a pre-existing Oracle software installation. In using this option, note the following:

  • You must complete the prerequisites for using Cluster Verification Utility, notably configuring SSH between all nodes in the cluster, before you can complete a clusterwide status check.

  • Cluster Verification Utility can assist you by finding preinstallation steps that need to be completed, but it cannot perform preinstallation tasks

Use the following syntax to determine what preinstallation steps are completed, and what preinstallation steps must be performed

$ ./runcluvfy.sh stage -pre crsinst -n node_list 

In the preceding syntax example, replace the variable node_list with the names of the nodes in your cluster, separated by commas.

For example, for a cluster with mountpoint /mnt/dvdrom/, and with nodes node1, node2, and node3, enter the following command:

$ cd /mnt/dvdrom/
$ ./runcluvfy.sh stage -pre crsinst -n node1,node2,node3

Review the Cluster Verification Utility report, and proceed to the sections of the preinstallation chapter to complete additional steps as needed.

2.14.3 Using the Cluster Verification Utility Help

The cluvfy commands have context-sensitive help that shows correct syntax usage based on the command line arguments that you enter.

If you enter an invalid Cluster Verification Utility command, then Cluster Verification Utility shows the correct usage for that command. For example, if you type runcluvfy.sh stage -pre dbinst, then Cluster Verification Utility shows the correct syntax for the database preinstallation checks that it performs with the dbinst stage option. The following is a list of context help commands.

  • cluvfy -help —Cluster Verification Utility displays detailed command information.

  • cluvfy comp -list—Cluster Verification Utility displays a list of components that can be checked, and brief descriptions of how each component is checked.

  • cluvfy comp -help—Cluster Verification Utility displays detailed syntax for each of the valid component checks.

  • cluvfy stage -list—Cluster Verification Utility displays a list of valid stages.

  • cluvfy stage -help—Cluster Verification Utility displays detailed syntax for each of the valid stage checks.

2.14.4 Using Cluster Verification Utility with Oracle Database 10g Release 1 or 2

You can use Cluster Verification Utility on the Oracle Database 11g release 1 (11.1) media to check system requirements for Oracle Database 10g release 1 (10.1) and later installations. To use Cluster Verification Utility to check 10. 2 installations, append the command flag -r 10gR2 to the standard system check commands.

For example, to perform a verification check for a Cluster Ready Services 10. 2 installation, on a system where the media mountpoint is /mnt/dvdrom, and the cluster nodes are node1, node2, and node3, enter the following command:

$ cd /mnt/dvdrom
$ ./runcluvfy.sh stage -pre crsinst -n node1,node2,node3 -r 10gR2

Note:

If you do not specify a release version to check, then Cluster Verification Utility checks for 11g release 1 (11.1) requirements.

2.14.5 Verbose Mode and "Unknown" Output

If you run Cluster Verification Utility using the -verbose argument, and it responds with UNKNOWN for a particular node, then this is because Cluster Verification Utility cannot determine if a check passed or failed. The following is a list of possible causes for an "Unknown" response:

  • The node is down

  • Executables required by Cluster Verification Utility are missing in the /bin directory in the Oracle Clusterware home or Oracle home directory

  • The user account starting Cluster Verification Utility does not have privileges to run common operating system executables on the node

  • The node is missing an operating system patch, or a required package

  • The node has exceeded the maximum number of processes or maximum number of open files, or there is a problem with IPC segments, such as shared memory or semaphores

2.15 Checking Oracle Clusterware Installation Readiness with CVU

Use Cluster Verification Utility (CVU) to check your servers for their readiness to install Oracle Clusterware:

As the installation owner user (oracle or crs), ensure that you have ssh keys loaded into memory, and enter a command using the following syntax to verify that your cluster is properly configured for Oracle Clusterware installation:

/mountpoint/runcluvfy.sh stage -pre crsinst -n node_list [-verbose]

In the preceding syntax example, the variable node_list is a comma-delimited list of nodes in your cluster. This command checks node reachability, user and group equivalence on each node, node connectivity, and basic system requirements, including kernel versions and packages.

Select the option -verbose to receive progress updates as Cluster Verification Utility performs its system checks, and detailed reporting of the test results.

For example, to verify system readiness on a two-node cluster with nodes node1 and node2, with the mountpoint /mnt/dvdrom, and with updates and a summary of the verification checks Cluster Verification Utility performs, enter the following command:

$ /mnt/dvdrom/runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose