Skip Headers
Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide
10g Release 2 (10.2) for hp Tru64

Part Number B14206-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Pre-Installation Tasks

This chapter describes the system configuration tasks that you must complete before you start Oracle Universal Installer. It includes information about the following tasks:

2.1 Understanding and Using Cluster Verification Utility

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

This section describes the following topics:

2.1.1 Entering Cluster Verification Utility Commands

Note:

You must have the utility unzip installed and configured with a path command for runcluvfy.sh to run.

Before the database is installed, to enter a CVU command, change directory and use the following syntax to start CVU:

$ /mountpoint/crs/Disk1/cluvfy/
$ ./runcluvfy.sh options

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

$ /dev/dvdrom/crs/Disk1/cluvfy/
$ ./runcluvfy.sh comp nodereach -n node1,node2 -verbose

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

Note:

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.

2.1.2 Using CVU to Determine if Installation Prerequisites are Complete

You can use CVU to determine which system prerequisites for installation are already completed. Use this option if you are installing Oracle 10g Release 2 (10.2) on a system with a pre-existing Oracle software installation. In using this option, note the following:

  • You must complete the prerequisites for using CVU

  • CVU can assist you by finding pre-installation steps that need to be completed, but it cannot perform pre-installation tasks

Use the following syntax to determine what pre-installation steps are completed, and what pre-installation 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 /dev/dvdrom/, and with nodes node1, node2, and node3, enter the following command:

$ cd /dev/dvdrom/crs/Disk1/cluvfy/
$ ./runcluvfy.sh stage -pre crsinst -n node1,node2,node3

Review the CVU report, and proceed to the sections of the pre-installation chapter to complete additional steps as needed.

2.1.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 CVU command, then CVU shows the correct usage for that command. For example, if you type runcluvfy.sh stage -pre dbinst, then CVU shows the correct syntax for the database pre-installation checks that CVU performs with the dbinst stage option. The following is a list of context help commands.

  • cluvfy: CVU displays high-level generic usage text describing the stage and component syntax.

  • cluvfy -help: CVU displays detailed CVU command information.

  • cluvfy comp -list: CVU displays a list of components that can be checked, and brief descriptions of how each component is checked.

  • cluvfy comp -help: CVU displays detailed syntax for each of the valid component checks.

  • cluvfy stage -list: CVU displays a list of valid stages.

  • cluvfy stage -help: CVU displays detailed syntax for each of the valid stage checks.

2.1.4 Using Cluster Verification Utility with Oracle 10g Release 1

You can use CVU on the Oracle 10g Release 2 (10.2) media to check system requirements for Oracle 10g Release 1 (10.1) installations. To use CVU to check 10. 1 installations, append the command flag -r 10gR1 to the standard CVU system check commands.

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

$ ./runcluvfy.sh stage -pre crsinst -n node1,node2,node3 -r 10gR1

2.1.5 Verbose Mode and "Unknown" Output

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

  • The node is down

  • Executables required by CVU are missing in the CRS_home /bin or Oracle home directory

  • The user account starting CVU 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.2 Logging In to the System as root

Before you install the Oracle software, you must complete several tasks as the root user. To log in as the root user, complete one of the following procedures:

2.3 Creating Required Operating System Groups and User

Depending on whether this is the first time Oracle software is being installed on this system and on the products that you are installing, you may need to create several operating system groups and an operating system user account.

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

The following operating system group and user are required for all installations:

A single Oracle Inventory group is required for all installations of Oracle software on the system. After the first installation of Oracle software, you must use the same Oracle Inventory group for all subsequent Oracle software installations on that system. However, you can choose to create different Oracle software owner users, OSDBA groups, and OSOPER groups (other than oracle, dba, and oper) for separate installations. By using different groups for different installations, members of these different groups have DBA privileges only on the associated databases rather than on all databases on the system.

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 and SYSOPER privileges

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

Note:

The following sections describe how to create local users and groups. As an alternative to creating local users and groups, you can create the appropriate users and groups in a directory service, such as Network Information Services (NIS). For information about using directory services, contact your system administrator or refer to your operating system documentation.

2.3.1 Creating the Oracle Inventory Group

Oracle Universal Installer (OUI) helps you to choose a group to use as the Oracle Inventory group. If you have an existing Oracle Inventory group, then provide this group name and path when prompted.

The following subsections describe how to determine the Oracle Inventory group name, if it exists, and how to create it if necessary.

Determining If the Oracle Inventory Exists

When you install Oracle software on the system for the first time, Oracle Universal Installer creates the oraInst.loc file. This file identifies the name of the Oracle Inventory group (typically, oinstall), and the path of the Oracle Inventory directory.

If you have an existing Oracle Inventory, then ensure that you use the same Oracle Inventory for all Oracle software installations.

If you do not have an existing Oracle Inventory, then you should create an Oracle Inventory group.

To determine whether you have an Oracle Inventory on your system, 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).

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

If the oraInst.loc file does not exist, then create the Oracle Inventory group by entering a command similar to the following:

# /usr/sbin/groupadd oinstall

2.3.2 Creating the OSDBA Group

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 dba

2.3.3 Creating an OSOPER Group (Optional)

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 oper

2.3.4 Creating the Oracle Software Owner User

You must create an Oracle software owner user 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, with different group membership, to give database administrative privileges to those groups in a new Oracle Database installation

Note:

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

Determining if an Oracle Software Owner User Exists

To determine whether an Oracle software owner user named oracle exists, enter the following command:

# id oracle

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

uid=440(oracle) gid=200(oinstall) groups=201(dba),202(oper)

If the user exists, then determine whether you want to use the existing user, or create another oracle 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.

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 the oracle user, enter a command similar to the following:

    # /usr/sbin/useradd -u 200 -g oinstall -G dba[,oper] 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 pre-installation.

    • 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
    
    

    Refer to the section "Verifying that the User nobody Exists".

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.

2.3.5 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 to create it:

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

2.3.6 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.

The Oracle software owner user 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, then create the user and groups with the same name and ID on the other cluster nodes.

Identifying the User and Group IDs

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

  1. Enter following command:

    # id oracle
    
    

    The output from this command is similar to the following:

    uid=440(oracle) gid=200(oinstall) groups=201(dba),202(oper)
    
    
  2. From the output, identify the user ID (UID) for the oracle user and the group identities (GIDs) for the groups to which it belongs.

Creating the User and Groups on the Other Cluster Nodes

To create the user 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 group. Use the -g option to specify the correct GID for each group.

    # /usr/sbin/groupadd -g 200 oinstall
    # /usr/sbin/groupadd -g 201 dba
    # /usr/sbin/groupadd -g 202 oper
    
    

    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 specify that ID for the group on all of the nodes.
  3. To create the oracle user, enter a command similar to the following:

    # /usr/sbin/useradd -u 200 -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 oracle user already exists, then use the usermod command to modify it if necessary. If you cannot use the same user ID for the oracle 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 oracle user:

    # passwd oracle
    

2.3.7 Configuring SSH on All Cluster Nodes

Before you install and use Oracle Real Application clusters, you must configure secure shell 2 (SSH2) for the oracle user on all cluster nodes. Oracle Universal Installer uses the ssh2 and scp commands during installation to run remote commands on and copy files to the other cluster nodes. You must configure SSH2 so that these commands do not prompt for a password.

Note:

This section describes how to configure Tru64 UNIX Secure Shell (SSH). Secure Shell is included as part of the Operating System for Tru64 UNIX Version 5.1B.

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

$ ps -aef | grep sshd

If SSH2 is running, then the response to this command is process ID numbers. To find out more about SSH2, enter the following command:

$ man ssh2

Also note that Oracle Net Configuration Assistant (NetCA) and Database Configuration Assistant (DBCA) require scp and ssh2 to be located in the path /usr/bin. If scp and ssh2 are not in this location, then create a symbolic link in /usr/bin to the location where scp and ssh2 are found.

2.3.7.1 Configuring SSH2 Authentication on Cluster Member Nodes

To configure SSH2, you must first create DSA and RSA keys on any cluster node. To do this task, complete the following steps:

2.3.7.1.1 Create DSA and RSA Keys

To create DSA and RSA keys:

  1. Log in as the oracle user.

  2. Enter the following commands to generate a DSA key for version 2 of the SSH protocol:

    /usr/bin/ssh-keygen2 -t dsa
    
    

    At the prompts:

    • Click Enter to accept the default location for the key file\

    • Enter and confirm a pass phrase that is different from the oracle user's password.

    This command writes the public key to the ~/.ssh/id_dsa_2048_a.pub file and the private key to the ~/.ssh/id_dsa_2048_a file. Never distribute the private key to anyone.

  3. Enter the following commands to generate an RSA key for version 2 of the SSH protocol:

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

    At the prompts:

    • Click Enter to accept the default location for the key file\

    • Enter and confirm a pass phrase that is different from the oracle user's password.

    This command writes the public key to the ~/.ssh/id_rsa_2048_a.pub file and the private key to the ~/.ssh/id_rsa_2048_a file. Never distribute the private key to anyone.

  4. Add keys to an authorized key file and identification file complete the following steps:

2.3.7.1.2 Add Keys to an Authorized Key File and Identification File

Complete the following steps:

  1. On the local node, determine if you have an authorized key file (~/.ssh2/authorization). If the authorized key file already exists, then proceed to step 2. Otherwise, enter the following commands:

    $ touch ~/.ssh2/authorization
    $ cd ~/.ssh2
    $ ls
    
    

    You should see the id_dsa_2048_a.pub and id_rsa_2048_a.pub keys that you have created, in adition to the authorization file.

  2. Add the ~/.ssh2/id_dsa_2048_a.pub and ~/.ssh/id_rsa_2048_a.pub key files to the file ~/.ssh2/authorization. For example:

    [oracle@node1 .ssh]$ echo Key id_dsa_2048_a.pub >> authorization
    [oracle@node1 .ssh]$ echo Key id_rsa_2048_a.pub >> authorization
    
    
  3. Add the ~/.ssh2/id_dsa_2048_a and ~/.ssh/id_rsa_2048_a key files to the file ~/.ssh2/identification. For example:

    [oracle@node1 .ssh]$ echo IdKey id_dsa_2048_a >> identification
    [oracle@node1 .ssh]$ echo IdKey id_rsa_2048_a >> identification
    
    

    Note:

    In this example, we assume that the Oracle user's home directory is shared on the cluster file system, and is not a CDSL-based home directory)
  4. Change the permissions on the oracle user's ~/.ssh2/authorization and ~/.ssh2/identification file:

    $ chmod 700 ~/.ssh2/authorization
    $ chmod 700 ~/.ssh2/identification
    
    

    At this point, if you use ssh2 to log in to or run a command on another node, you are prompted for the pass phrase that you specified when you created the DSA key.

2.3.7.1.3 Enabling SSH2 User Equivalency on Cluster Member Nodes

To enable user equivalency, 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-agent2 $SHELL
    $ /usr/bin/ssh-add2
    
    

    At the prompts, enter the pass phrase for each key that you generated.

    Note:

    You must run Oracle Universal Installer from this same terminal session, or remember to repeat step 2 before you start Oracle Universal Installer from a different terminal session.
  3. Test your SSH2 configuration with a command similar to the following:

    $ ssh2 node2 date
    
    

    If you have configured SSH2 correctly, then you should receive a response to the command, and you should be able to use ssh2 or scp commands without being prompted for a password or pass phrase.

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

Note:

The first time you use SSH2 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.

2.3.7.1.4 Preventing X11 Forwarding Errors

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

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

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

    Host *
          ForwardX11 no
    
    

2.3.7.2 Setting Remote Display

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, Korn and Bash shells:

$ export DISPLAY=hostname:0

C Shell:

$ setenv DISPLAY 0

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

$ export DISPLAY=node1:0

2.3.7.3 Preventing Oracle Clusterware Installation Errors Caused by stty Commands

During an Oracle Clusterware installation, Oracle Universal Installer uses SSH2 (if available) to run commands and copy files to the other nodes. During the installation, hidden files on the system (for example, .bashrc or .cshrc) will cause 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, Bash, 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:

    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.4 Configuring the oracle User's Environment

You run Oracle Universal Installer from the oracle account. However, before you start Oracle Universal Installer you must configure the environment of the oracle user.

To configure the environment, you must:

You should also ensure that the PATH variable contains $ORACLE_HOME/bin before /usr/X11R6/bin

To set the oracle user's environment, follow these steps:

  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 oracle user.

  4. If you are not logged in as the oracle user, then switch user to oracle:

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

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

    • Bourne shell (sh), Bash shell (bash) or Korn shell (ksh):

      % vi .bash_profile
      
      
    • C shell (csh or tcsh):

      % vi .login
      
      
  7. Enter or edit the following line, specifying a value of 022 for the default file mode creation mask:

    umask 022
    
    
  8. If the ORACLE_SID, ORACLE_HOME, or ORACLE_BASE environment variable is set in the file, then remove the appropriate lines from the file.

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

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

    • Bash shell:

      $ . ./.bash_profile
      
      
    • Bourne, Bash, or Korn shell:

      $ . ./.profile
      
      
    • C shell:

      % source ./.login
      
      
  11. 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, Bash, 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 Oracle Universal Installer (your workstation or PC).

  12. 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 RAC installation. If you place /tmp on a shared file system, then the installation fails.
    1. Use the df -h 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 775 /mount_point/tmp
      # exit
      
      
    3. Enter commands similar to the following to set the TEMP and TMPDIR environment variables:

      • Bourne, Bash, 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
        
        

2.5 Checking the Hardware Requirements

Each system must meet the following minimum hardware requirements:

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

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

    # /bin/vmstat -P | grep "Total Physical 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:

    # /sbin/swapon -s
    
    

    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:

    • # df -k /tmp
      
      

    This command displays disk space in 1 kilobyte blocks.

    Alternatively, with HP Tru64 version 5.1 B or later, you can use the df -h command, which displays disk space in gigabyte or megabyte blocks.

    If there is less than 400 MB of disk space available in the /tmp directory (less than 4194304 1-k blocks), 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).

    • 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:

    • # df -h
      
      

    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 at least 1.5
    Standard Edition at least 1.5
    Custom (maximum) at least 1.5

2.6 Checking the Network Requirements

Check that you have the networking hardware and internet protocol (IP) addresses required for an Oracle Real Application Clusters installation. This section contains the following:

Note:

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

2.6.1 Checking IP Address Requirements

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

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

  • One virtual IP (VIP) address with an associated network name registered in DNS. If you do not have an available DNS, then record the network 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 network name are currently unused

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

    Before installation, check that the default gateway can be accessed by a ping command. During installation, OUI uses the ping command to ensure that the VIP is reachable. 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 network name associated with the VIP. If a node fails, then the node's virtual IP address fails over to another node.

  • 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.*.*). Use the /etc/hosts file on each node to associate private network names with private IP addresses.

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 Interface Name Type IP Address Registered In
rac1 rac1 Public 143.46.43.100 DNS (if available, else the hosts file)
rac1 rac1-vip Virtual 143.46.43.104 DNS (if available, else the hosts file)
rac1 rac1-priv Private 10.0.0.1 Hosts file
rac2 rac2 Public 143.46.43.101 DNS (if available, else the hosts file)
rac2 rac2-vip Virtual 143.46.43.105 DNS (if available, else the hosts file)
rac2 rac2-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. When a node or interconnect fails, then the associated VIP is relocated to the surviving instance, enabling fast notification of the failure to the clients connecting through that VIP. If the application and client are configured with transparent application failover options, then the client is reconnected to the surviving instance.

2.6.2 Checking Network Hardware Requirements

Each node in the cluster must meet the following requirements:

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

  • 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 increased reliability, configure redundant public and private network adapters for each node.

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

  • For the private network, Oracle supports the following interconnect protocols and hardware:

    • Reliable datagram (RDG) using Memory Channel adapters and hubs

    • RDG or user datagram protocol (UDP) using high-speed network adapters and switches that support TCP/IP (Gigabit Ethernet or better recommended)

    Note:

    On HP Tru64, RDG is the default interconnect protocol (IPC) for RAC, and TCP is the interconnect protocol for Oracle Clusterware.

    When the Oracle Real Application Clusters option is enabled, the Global Cache Service (GCS), Global Enqueue Service (GES), Interprocessor Parallel Query (IPQ), and Cache Fusion use RDG. The User Datagram Protocol (UDP) IPC implementation is still available but you must enable it explicitly.

    To use UDP as the interconnect protocol for RAC, you must relink the Oracle executable. Refer to Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more information about enabling UDP for RAC on Tru64 UNIX systems.

    Token-Ring is not supported 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. You can test whether an interconnect interface is reachable using a ping command.

2.6.3 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. Register the host names and IP addresses for the public network interfaces in DNS.

  3. For each node, register one virtual host name and IP address in DNS.

  4. For each private interface on every node, add a line similar to the following to the /etc/hosts file on all nodes, specifying the private IP address and associated private host name:

    10.0.0.1     rac1-priv1
    
    
  5. To identify the interface name and associated IP address for every network adapter, enter the following command:

    # /sbin/ifconfig
    
    

    From the output, identify the interface name and IP address for all network adapters that you want to specify as public or private network interfaces.

    Note:

    When you install Oracle Clusterware and RAC, you will require this information.
  6. To prevent network hangs with failovers from public to virtual IP addresses with RAC databases using NAS devices or NFS mounts, enter the following command as root to enable the Name Service Cache Daemon (nscd):

    # /sbin/service  nscd start
    
    

2.6.4 Checking 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.

Many Oracle processes are timed, especially if the initialization parameter TIMED_STATISTICS is set to true. These timing functions call the HP Tru64 kernel, and can affect Oracle Database performance. You can improve performance on heavily loaded systems by enabling processes to access the real time clock directly.

To enable access to the real time clock:

  1. Log in as the root user.

  2. Enter the following commands on one cluster node.:

    # mknod /dev/timedev c 15 0 
    # chmod a+r /dev/timedev
    
    

    Note:

    The special file /dev/timedev remains on the system after restarts.
  3. Restart the Oracle Database instance.

    The system checks for the existence of the /dev/timedev file only on instance startup.

  4. Repeat steps 1 through 3 on each node of the cluster.

2.6.5 Configuring Asynchronous I/O

Oracle Database for Tru64 UNIX systems can perform either synchronous or asynchronous I/O. To improve performance, Oracle recommends that you use asynchronous I/O. Set the DISK_ASYNC_IO initialization parameter to true to enable asynchronous I/O.

Oracle Database can use asynchronous I/O on any datafiles that are stored on AdvFS or clustered file systems (CFS), in Automatic Storage Management disk groups, or on raw devices. You must tune some kernel subsystem attributes for optimal asynchronous I/O performance.

2.7 Checking the Network Setup with CVU

As the oracle user, enter a command using the following syntax to verify node connectivity among all of the nodes for which your cluster is configured:

/mountpoint/crs/Disk1/cluvfy/runcluvfy.sh comp nodecon -n node_list [-verbose]

In the preceding syntax example, the variable node_list is a comma-separated list of nodes in your cluster. This command detects all the network interfaces available on the cluster nodes, and verifies the connectivity among all the nodes through the network interfaces it finds.

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

For example, to verify node connectivity on a two-node cluster with nodes node1 and node2, with the mountpoint /dev/dvdrom, and with updates and a summary of the verification checks the CVU performs, enter the following command:

/dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh comp nodecon -n node1,node2 -verbose

Note:

You can use this command to obtain a list of all the interfaces available on the nodes that are suitable for use as VIPs, as well as a list of private interconnects that are connecting successfully on all nodes.

2.8 Verifying Software Requirements

Depending on the products that you intend to install, verify that the following software is installed on the system. To check these requirements refer to the section "Checking the Software Requirements", following this section.

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.

2.8.1 Software Requirements List for HP Tru64 Platforms

Table 2-1 HP Tru64 System Requirements

Item Requirement

All installations

Operating system version:

HP Tru64 UNIX 5.1B-3 (patchkit 5)

 

The following operating system subsets must be installed:

OSFCMPLRS
OSFLIBA
OSFPGMR
OSFSER
OSFX11

Oracle Real Application Clusters

HP TruCluster 5.1B:

TCRBASE
TCRMIGRATE

Oracle Spatial

X Window and X/Motif software:

OSFXDEVX
OSFXINCLUDE
OSFXLIBA

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

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

Compaq C Compiler version DEC 6.5-207 developer's toolkit supplement (dtk):

DTCCMPLR

Compiler Driver V6.5-207 (dtk) cc Driver V6.5-207 (dtk)

Entrust IPSec Toolkit for C 6.0

Entrust Server Login 6.0

GNU C compiler gcc version 3.0

Compaq C++ Compiler (cxx) version DEC 6.5-014:

CXXBASE
CXXLIB
CXXOLD

Pro*COBOL

Micro Focus Server Express for Tru64 2.2

Pro*FORTRAN

Compaq Fortran 5.4A

Oracle JDBC/OCI Drivers

You can use the following optional JDK versions with the Oracle JDBC/OCI drivers; however, they are not required for the installation:

  • SDK v. 1.3.1-5

  • SDK v 1.2.2-12

Note: SDK v 1.4.2 is installed by Oracle Universal Installer.


2.8.2 Checking the Software Requirements

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

  1. To determine which version of Tru64 is installed, enter the following command:

    # /usr/sbin/sizer -v
    Compaq Tru64 UNIX V5.1B (Rev. 2650); Mon Nov  3 10:13:28 PST 200
    
    

    In this example, the version shown is V5.1B. If necessary, refer to your operating system documentation for information about upgrading the operating system.

  2. To determine whether Java SDK 1.4.2 is installed, enter the following command:

    # /usr/sbin/setld -i JAVA142 | more
    
    

    If Java SDK 1.4.2 is installed, this command displays the paths to all of the installed files. Note the path of the Java home directory. You must specify this value during the installation. The default path is:

    /usr/opt/java142
    
    

    If this command returns the message Unknown subset, then Java SDK 1.4.2 is not installed. You must have at least Java SDK 1.4.2-3 or higher. Download the Java SDK from the following Web site and install it:

    http://www.compaq.com/java/download/index.html
    
    
  3. To determine whether the required software subsets are installed, enter one of the following commands:

    • To view the list of all software subsets installed on the system, enter the following command:

      # /usr/sbin/setld -i | more
      
      
    • To determine whether a particular software subset is installed, enter a command similar to the following:

      # /usr/sbin/setld -i | grep subsetname
      
      

    If necessary, install the required software subset. If you require the Compaq C Compiler V6.5-207 (dtk), you can download it from the following Web site:

    http://www.tru64unix.compaq.com/dtk/
    
    
  4. To determine whether X Window and X/Motif packages are installed, enter a command similar to the following:

    $ setld -i |grep Window 
    
    
  5. If you intend to use Oracle Messaging Gateway and require MQSeries classes for Java and MQSeries classes for Java Message Service (SupportPac MA88), download it from the following Web site:

    http://www.ibm.com/support
    

2.9 Verifying Required Patches

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

2.9.1 Patch Requirements List for HP Tru64

Table 2-2 Required Patches for HP Tru64 UNIX

Installation Type or Product Requirement

All installations

Tru64 UNIX V5.1B Patch Kit 5 or higher:

T64V51BB26AS0005-20050502

Oracle Messaging Gateway

Corrective service diskette (CSD) for MQSeries:

CSD09 or later for MQSeries V5.1


2.9.2 Checking the Patch Requirements

To determine whether the required patch kits are installed, enter the following command:

# /usr/sbin/dupatch -track -type kit

If this command does not display the identifiers shown in the previous table for the required patch kits (or the identifier for a higher patch kit level), download the latest patch kit from the following Web site and install it (registration is required to access this Web site):

http://itrc.hp.com/service/patch/mainPage.do

If you require a CSD for MQSeries, refer to the following Web site for download and installation information:

http://www.ibm.com/software/integration/mqfamily/support/summary/dig.html

2.10 Configuring Kernel Subsystem Attributes

Note:

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

On all cluster nodes, verify that the kernel subsystem attributes are set to values greater than or equal to the recommended value shown.

To view the current value specified for these kernel subsystem attributes, and to change them if necessary, follow these steps:

  1. Log in as root, and make a copy of your existing /etc/sysconfigtab file. For example:

    # cp /etc/sysconfigtab /etc/sysconfigtab.orig
    
    
  2. Using a text editor, create a stanza-formatted modification file called sysconfigmod for the /etc/sysconfigtab file, with the following contents:

    vfs:
         fifo_do_adaptive=0 
    
    
  3. Using the following command, merge the contents of sysconfigmod with the existing /etc/sysconfigtab file:

    # sysconfigdb -m -f sysconfigmod
    
    
  4. Use the following command syntax to confirm this change, and to determine the current values of subsystem attributes:

    # /sbin/sysconfig -q subsystem
    
    

    In the preceding syntax example, replace the variable subsystem with the name of the subsystem whose value you want to check.

    For example, to check the attribute values of the ipc subsystem, enter the following command:

    # /sbin/sysconfig -q ipc
    
    

    To check the attribute values of the proc subsystem, enter the following command:

    # /sbin/sysconfig -q proc 
    
    

    To check the attribute values of the rdg subsystem, enter the following command:

    # /sbin/sysconfig -q rdg
    
    

    Check the kernel subsystems listed in the following table:

    Note:

    Make a note of the current values and identify any values that you must change.

    Table 2-3 Required Values for HP Tru64 Kernel Subsystem Attributes

    Subsystem Attribute Recommended Value

    ipc

    shm_max

    4278190080 (4 GB minus 16 MB)

    shm_min

    1

    shm_mni

    256

    shm_seg

    256

    ssm_threshold

    Set this attribute to 0 only if the rad_gh_regions[n] or gh_chunks attributes are set in the vm subsystem. Otherwise, do not change the value.

    proc

    exec_disable_arg_limit

    1

    per_proc_stack_size

    8388608 (8 MB)Foot 1 

    max_per_proc_stack_size

    33554432 (32 MB)Footref 1

    per_proc_data_size

    335544320 (320MB)

    max_per_proc_data_size

    335544320 (320MB)

    max_per_proc_address_space

    Equal to the size of RAM or 1073741824 (1 GB), whichever is larger.

    per_proc_address_space

    Equal to the size of RAM or 1073741824 (1 GB), whichever is larger.

    rdg

    msg_size

    32768

    max_objs

    5120

    max_async_req

    256

    max_sessions

    500 (or at least 20 plus the value of the PROCESSES initialization parameter for all databases on the system, if this value is higher.)

    rdg_max_auto_msg_wires

    0

    rdg_auto_msg_wires

    0

    rt

    aio_task_max_num

    8193

    vfs

    fifo_do_adaptive

    0


    Footnote 1 The maximum value supported by Oracle for this parameter is 512 MB.

    Note:

    The vfs parameter new_wire_method is obsoleted with the current patchset for HP Tru64.
  5. If you must change any of the current values, then follow these steps:

    1. Create a backup copy of the /etc/sysconfigtab file. For example:

      # cp /etc/sysconfigtab /etc/sysconfigtab.mod1
      
      
    2. Using any text editor, create a stanza-formatted file similar to the following, specifying the subsystems and attributes that you want to modify:

      ipc:
           shm_max = 4278190080
           shm_min = 1
           shm_mni = 256
           shm_seg = 128
      
      proc:
           exec_disable_arg_limit = 1
           per_proc_stack_size = 8388608
           max_per_proc_stack_size = 33554432
           per_proc_data_size = 335544320
           max_per_proc_data_size = 335544320
           max_per_proc_address_space = 4294967296
           per_proc_address_space = 4294967296
      
      rdg:
        msg_size = 32768
        max_objs = 5120
        max_async_req = 256
        max_sessions = 500
        rdg_max_auto_msg_wires = 0
        rdg_auto_msg_wires = 0
      
      
    3. Enter a command similar to the following to merge the missing or modified subsystem attributes to the /etc/sysconfigtab file:

      # /sbin/sysconfigdb -m -f filename
      
      

      In this example, filename is the name of the file you created in step b.

    4. Enter the following command to restart the system:

      # /sbin/shutdown -r now
      
      
    5. When the system restarts, log in and switch user to root.

  6. (Optional) If you have a db_block_size of 16 KB or greater, and you are using UDP IPC implementation, then edit the inet parameter in the /etc/sysconfigtab file to be at least the following:

    inet: udp_recvspace = 65536
    udp_sendspace = 65536
    
    

    Note:

    Default IPC for Oracle Real Application Clusters is RDG
  7. Repeat this procedure on all other cluster nodes.

2.10.1 Configuring Reliable Datagram (RDG)

Reliable Data Gram (RDG) is an IPC infrastructure for the Tru64 UNIX TruCluster platform. It is the default IPC method for Oracle Database on Tru64 UNIX and is optimized for Oracle Real Application Clusters environments.

To use reliable datagram (RDG) for IPC:# make -f ins_rdbms.mk rac_on# make -f ins_rdbms.mk ioracle

To use RDG, each node must be a member of the cluster and connected through the memory channel. Oracle recommends that you set the node-wide subsystem attributes listed in Table 2-4 when using RDG.

Table 2-4 rdg Subsystem Attribute Settings

Attribute Setting

max_objs

At least 5 times the number of Oracle processes per node, and up to the larger value either of 10240, or of the number of Oracle processes multiplied by 70.

msg_size

Equal to or greater than the maximum value of the DB_BLOCK_SIZE parameter for the database.

Oracle recommends to set the value of msg_size to 32768, because Oracle Database supports different block sizes for each tablespace.

max_async_req

At least 100, or the operating system default, whichever is larger.

Note: Depending on system load, a value of 1000 or greater may provide better performance.

max_sessions

170 (20 + value of Oracle PROCESSES initialization parameter).

rdg_max_auto_msg_wires

Must be set to 0.


2.11 Checking the Hardware and Operating System Setup with CVU

As the oracle user, use the following command syntax to start Cluster Verification Utility (CVU) stage verification to check hardware and operating system setup:

/mountpoint/crs/Disk1/cluvfy/runcluvfy.sh stage –post hwos –n node_list [-verbose]

In the preceding syntax example, replace the variable node_list with the names of the nodes in your cluster, separated by commas. For example, to check the hardware and operating system of a two-node cluster with nodes node1 and node2, with the mountpoint /dev/dvdrom/ and with the option to limit the output to the test results, enter the following command:

/dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh stage –post hwos –n node1,node2

Select the option -verbose to receive detailed reports of the test results, and progress updates about the system checks performed by Cluster Verification Utility.

2.12 Checking the Operating System Requirements Setup with CVU

As the oracle user, use the following command syntax to check if your system meets the operating system requirement pre-installation tasks:

/mountpoint/crs/Disk1/cluvfy/runcluvfy.sh comp sys -n node_list -p {crs|database} -osdba osdba_group -orainv orainv_group -verbose

In the preceding syntax example:

You can select the option -verbose to receive progress updates as the CVU performs its system checks, and detailed reporting of the test results.

For example, to perform a system check for an Oracle Clusterware installation on a two-node cluster with nodes node1 and node2, with the OSDBA dba and Oracle inventory group oinstall, and with the media mountpoint /dev/dvdrom/, then enter the following command:

/dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh comp sys -n node1,node2 -p crs -osdba crs -orainv oinstall

2.13 Identifying Required Software Directories

You must identify or create the following directories for the Oracle software, as follows:

The following subsections describe the requirements for these directories.

Oracle Base Directory

The Oracle base directory acts as a top-level directory for Oracle software installations. Optimal Flexible Architecture (OFA) guidelines recommend that you use a path similar to the following for the Oracle base directory:

/mount_point/app/oracle_sw_owner

In this example:

You can use the same Oracle base directory for more than one installation or you can create separate Oracle base directories for different installations. If different operating system users install Oracle software on the same system, then each user must create a separate Oracle base directory. The following example Oracle base directories could all exist on the same system:

/u01/app/oracle
/u01/app/orauser
/opt/oracle/app/oracle

The following sections describe how to identify existing Oracle base directories that might be suitable for your installation and how to create an Oracle base directory if necessary.

Regardless of whether you create an Oracle base directory or decide to use an existing one, you must set the ORACLE_BASE environment variable to specify the full path to the Oracle base directory.

Note:

The Oracle base directory must be on a cluster file system.

Oracle Inventory Directory

The Oracle Inventory directory (oraInventory) stores an inventory of all software installed on the system. It is required by, and shared by, all Oracle software installations on a single system. The first time you install Oracle software on a system, Oracle Universal Installer prompts you to specify the path to this directory. If you are installing the software on a local file system, then Oracle recommends that you choose the following path:

oracle_base/oraInventory

As the Oracle base directory is located on a cluster file system, you must place the Oracle Central Inventory directory on a local file system, privately mounted on each node, so that each node has a separate copy of the central inventory.

If you specify a shared location for the Oracle Central Inventory, then each node attempts to write to the same central inventory. This is not supported.

Oracle Universal Installer creates the directory that you specify, and sets the correct owner, group, and permissions for it. You do not need to create it.

Note:

All Oracle software installations rely on the Oracle base directory. Make sure that you back it up regularly.

Do not delete the Oracle base directory unless you have completely removed all Oracle software from the system.

Oracle Clusterware Home Directory

The Oracle Clusterware home directory is the directory where you choose to install the software for Oracle Clusterware. You must install Oracle Clusterware in a separate home directory. When you run Oracle Universal Installer, it prompts you to specify the path to this directory, as well as a name that identifies it. Oracle recommends that you specify a path similar to the following for the Oracle Clusterware home directory:

/u01/app/oracle/product/crs

Note:

Because you must change the permissions of all of the parent directories of the Oracle Clusterware home directory after installing the software to grant write access only to the root user, the Oracle Clusterware home directory must not be a subdirectory of the Oracle base directory.

Oracle Home Directory

The Oracle home directory is the directory where you choose to install the software for a particular Oracle product. You must install different Oracle products, or different releases of the same Oracle product, in separate Oracle home directories.

Note:

The Oracle Home directory must be on a cluster file system.

When you run Oracle Universal Installer, it prompts you to specify the path to this directory, as well as a name that identifies it. The directory that you specify must be a subdirectory of the Oracle base directory. Oracle recommends that you specify a path similar to the following for the Oracle home directory:

oracle_base/product/10.2.0/db_1

Oracle Universal Installer creates the directory path that you specify under the Oracle base directory. It also sets the correct owner, group, and permissions on it. You do not need to create this directory.

Caution:

During the installation, you must not specify an existing directory that has predefined permissions applied to it as the Oracle home directory. If you do, then you may experience installation failure due to file and group ownership permission errors.

2.14 Identifying or Creating an Oracle Base Directory

Before starting the installation, you must either identify an existing Oracle base directory or if required, create one. This section contains information about the following:

Note:

You can choose to create an Oracle base directory, even if other Oracle base directories exist on the system.

Identifying an Existing Oracle Base Directory

Existing Oracle base directories might not have paths that comply with OFA guidelines. However, if you identify an existing Oracle Inventory directory or existing Oracle home directories, you can usually identify the Oracle base directories, as follows:

Before deciding to use an existing Oracle base directory for this installation, make sure that it satisfies the following conditions:

If an Oracle base directory does not exist on the system, or if you want to create an Oracle base directory, then refer to the following section.

Creating an Oracle Base Directory

Before you create an Oracle base directory, you must identify an appropriate file system. The Oracle base directory requires at least 1.5 GB of free disk space.

To identify an appropriate file system, follow these steps:

  1. Use the df -h command to determine the free disk space on each mounted file system.

  2. From the display, identify a file system that has appropriate free space.

    Note:

    The Oracle base directory must be on a cluster file system.

    The path to the Oracle base directory must be the same on all nodes.

  3. Note the name of the mount point directory for the file system that you identified.

To create the Oracle base directory and specify the correct owner, group, and permissions for it, follow these steps:

  1. Enter commands similar to the following to create the recommended subdirectories in the mount point directory that you identified, and to set the appropriate owner, group, and permissions on them:

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

    For example, if the mount point you identify is /u01, and oracle is the user name of the Oracle software owner, then the recommended Oracle base directory path is as follows:

    /u01/app/oracle
    
    
  2. If necessary, repeat the commands listed in the previous step to create the same directory on the other nodes in the cluster.

  3. When you configure the oracle user's environment later in this chapter, set the ORACLE_BASE environment variable to specify the Oracle base directory you have created in this task.

2.15 Creating the Oracle Clusterware Home Directory

Oracle Universal Installer (OUI) creates the Oracle Clusterware home directory for you. Ensure before you start the installation that you provide sufficient disk space on a file system for the Oracle Clusterware directory, and the parent directory of the Oracle Clusterware directory space is writable by the oracle user.

To identify an appropriate file system, follow these steps:

  1. Use the df -h command to determine the free disk space on each mounted file system.

  2. From the display, identify a file system that has at least 1.4 GB of free disk space.

    If you are using the same file system for the Oracle base directory, then this 1.4 GB of disk space is additional to the free disk space requirement that you identified previously.

    Note:

    The file system must be a cluster file system.

    The path to the Oracle Clusterware home directory must be the same on all nodes.

  3. Note the name of the mount point directory for the file system that you identified.

To create the Oracle Clusterware home directory and specify the correct owner, group, and permissions for it, follow these steps:

  1. Enter commands similar to the following to create the recommended subdirectories in the mount point directory that you identified and set the appropriate owner, group, and permissions on them:

    # mkdir -p /mount_point/crs/oracle_sw_owner/product/10/app
    # chown -R root:oinstall /mount_point/crs
    # chmod -R 775 /mount_point/crs/oracle_sw_owner
    
    

    If the mount point you identified is /u01, then the recommended Oracle Clusterware home directory path is as follows:

    /u01/crs/oracle/product/10/crs
    
    

    Note:

    After installation, you should change permissions so that only the root user can write to the Oracle Clusterware home directory.
  2. If necessary, repeat the commands listed in the previous step to create the same directory on the other nodes in the cluster.

  3. Enter commands similar to the following to set the ORACLE_BASE and ORACLE_HOME environment variable in preparation for the Oracle Clusterware installation:

    • Bourne, Bash, or Korn shell:

      $ ORACLE_BASE=/u01/app/oracle
      $ ORACLE_HOME=/u01/crs/oracle/product/10/app
      $ export ORACLE_BASE
      $ export ORACLE_HOME
      
      
    • C shell:

      % setenv ORACLE_BASE /u01/app/oracle
      % setenv ORACLE_HOME /u01/crs/oracle/product/10/app
      
      
  4. Enter the following commands to ensure that the TNS_ADMIN environment variable is not set:

    • Bourne, Bash, or Korn shell:

      $ unset TNS_ADMIN
      
      
    • C shell:

      % unsetenv TNS_ADMIN
      
      
  5. To verify that the environment has been set correctly, enter the following commands:

    $ umask
    $ env | more
    
    

    Verify that the umask command displays a value of 22, 022, or 0022 and the environment variables that you set in this section have the correct values.

2.16 Overview of the Spike Optimalization Tool

The Spike optimization tool (Spike) is a performance optimization tool that increases the performance of the Tru64 UNIX binary. In a testing environment, Spike, with feedback, increased the performance of Oracle Database by up to 23 percent on an OLTP workload.

For information about Spike, refer to the Tru64 UNIX documentation, or enter one of the following commands:

man spike
spike

See Also:

Oracle Database Administrator's Reference for UNIX-Based Operating Systems for additional configuration and recommendations for using Spike.

2.17 Stopping Existing Oracle Processes for Upgrades or Co-existing Databases

Table 2-5 provides an overview of what you need to do if you have an existing Oracle database on the system where you plan to install Oracle Database 10g Release 2 (10.2). Review the table, and perform tasks as required.

See Also:

Oracle Database Upgrade Guide for additional information about preparing for and performing upgrades.

Table 2-5 Overview of System Preparation for Upgrades or Co-existing Databases

Installation Scenario What you need to do

Upgrading from Oracle Database 10g Release 1 (10.1) to 10g Release 2 (10.2)

No additional tasks. Refer to Installing Oracle 10g Release 2 on a System with Oracle 10g Release 1

installing Oracle Database 10g Release 2 (10.2) on a system to co-exist with Oracle Database 10g Release 1 (10.1)

No additional tasks. Refer to Installing Oracle 10g Release 2 on a System with Oracle 10g Release 1

Upgrading from Oracle9i Release 9.2 to Oracle Database 10g Release 2 (10.2)

Shut down the Global Service Daemon, and shut down a default listener on port 1521, if present. Refer to Installing Oracle 10g Release 2 on a System with Oracle9i Release 2

Installing Oracle Database 10g Release 2 (10.2) on a system to co-exist with Oracle9i Release 9.2

Shut down a default listener on port 1521, if present, and shut down the Global Service Daemon. Refer to Installing Oracle 10g Release 2 on a System with Oracle9i Release 2


Installing Oracle 10g Release 2 on a System with Oracle 10g Release 1

If your system has an Oracle Database Release 10g Release 10. 1 installation, and you install an Oracle Database 10g Release 2 (10.2) either to coexist with or to upgrade the 10.1, then most installation types configure and start a default Oracle Net listener using TCP/IP port 1521 and the IPC key value EXTPROC. One of the following occurs:

Proceed to Chapter 3.

Installing Oracle 10g Release 2 on a System with Oracle9i Release 2

This section provides instructions for preparing

Explanation of Tasks If you are installing an Oracle Database 10g Release 2 (10.2) on a system with an existing Oracle9i Release 2 (9.2) database, and the Oracle Net listener process is using the same port or key value as the default used with the Oracle 10g Release 2 (10.2) installation, port 1521, then Oracle Universal Installer can only configure the new listener; it cannot start it. To ensure that the new listener process starts during the installation, you must shut down any existing listeners before starting Oracle Universal Installer. To do this, refer to "Shutting Down the Listener"

You must shut down the Global Services Daemon (GSD), because otherwise, during 10g Release 2 (10.2) installation, the Oracle9i Release 9.2 SRVM shared data is upgraded into an Oracle Cluster Registry that the 9.2 GSD will not be able to use. The 10.2 Oracle Clusterware installation starts a 10g Release 2 (10.2) GSD to serve the Oracle9i 9.2 clients. To do this, refer to "Shutting down the Global Services Daemon"

Shutting Down the Listener To determine whether an existing Oracle9i listener process is running and to shut it down if necessary, follow these steps:

  1. Switch user to oracle:

    # su - oracle
    
    
  2. Enter the following command to determine whether an Oracle9i listener process is running and to identify its name and the Oracle home directory in which it is installed:

    $ ps -ef | grep tnslsnr
    
    

    This command displays information about the Oracle Net listeners running on the system:

    ... oracle_home1/bin/tnslsnr LISTENER -inherit
    
    

    In this example, oracle_home1 is the Oracle home directory where the listener is installed and LISTENER is the listener name.

    Note:

    If no Oracle Net listeners are running, then proceed to Chapter 3.
  3. Set the ORACLE_HOME environment variable to specify the appropriate Oracle home directory for the listener:

    • Bourne, Bash, or Korn shell:

      $ ORACLE_HOME=oracle_home1
      $ export ORACLE_HOME
      
      
    • C or tcsh shell:

      % setenv ORACLE_HOME oracle_home1
      
      
  4. Enter the following command to identify the TCP/IP port number and IPC key value that the listener is using:

    $ $ORACLE_HOME/bin/lsnrctl status listenername
    

    Note:

    If the listener uses the default name LISTENER, then you do not have to specify the listener name in this command.
  5. Enter a command similar to the following to stop the listener process:

    $ $ORACLE_HOME/bin/lsnrctl stop listenername
    
    
  6. Repeat this procedure to stop all listeners running on this system and on all other nodes in the cluster.

Shutting down the Global Services Daemon As the oracle user, on each node of the cluster, use the following syntax to shut down the GSD:

$ cd 92_Oracle_home
$ bin/gsdctl stop

In the preceding syntax example, the variable 92_Oracle_home is the Oracle9i Release 2 (9.2) database home.