2
Pre-Installation Requirements

Installation Requirements

Verify that your system meets the hardware, disk space, operating system, and other requirements for installing the Oracle9i database.

Installation Recommendations

Oracle Corporation recommends the following installation configuration step.

Setup Tasks to Perform as root User

The following pre-installation setup tasks configure your system and set up the accounts, groups, variables and permissions needed to run the Oracle9i database. If you choose not to perform these tasks prior to installation, then you will be given the option during the installation process to log in as root user and run the orainstRoot.sh script. The orainstRoot.sh script performs many of these setup tasks for you but might not provide a satisfactory environment for your system. Oracle Corporation recommends that you perform these steps manually.

To set up your environment for Oracle9i database, log in as the root user and perform the following tasks for your platform:

• Configure Kernel Parameters

• Create Mount Points

• Create UNIX Groups for Database Administrators

• Create a UNIX Group for the Oracle Universal Installer Inventory

• Create a UNIX Account to Own Oracle Software

• Create a UNIX Account to Own the Oracle HTTP Server

• Set Permissions for File Creation

Oracle9i uses UNIX resources such as shared memory, swap memory, and semaphore extensively for interprocess communication. If your parameter settings are insufficient for Oracle9i, then you will experience problems during installation and instance startup. The greater the amount of data you can store in memory, the faster your database will operate. In addition, by maintaining data in memory, the UNIX kernel reduces disk I/O activity.

Review your kernel parameter settings to ensure that they meet Oracle9i requirements. If you do not do this, you may experience errors during installation, or operational errors after installation. These are the recommended kernel parameter requirements for a typical Oracle9i environment. If you have previously tuned your kernel parameters to levels that meet your application needs, then continue to use these values. A system restart is necessary if you change the kernel settings for the kernel changes to take effect.

Refer to the appropriate tables for the kernel parameters for your platform.

• Kernel Parameter Settings for AIX

• Kernel Parameter Settings for HP

• Kernel Parameter Settings for Linux

• Kernel Parameter Settings for Solaris

• Kernel Parameter Settings for Tru64

AIX does not require kernel parameter configuration prior to Oracle9i installation. However, certain system parameters may need to be adjusted to increase performance.

For HP, you may use the System Administrator's Menu (SAM) to configure the HP kernel as required by your application. The parameters in the following table are those recommended for a general user running a typical Oracle9i single database instance on HP. You may need to change the values per your application needs and the type of system you are working on. Refer to the following table to determine if your system shared memory and semaphore kernel parameters are set correctly for Oracle9i. Use the ipcs command to obtain a list of the system's current shared memory and semaphore segments, and their identification numbers and owner.

The parameters in the following table are the recommended values to run Oracle9i with a single database instance on HP.

For Linux, use the ipcs command to obtain a list of the system's current shared memory segments and semaphore sets, and their identification numbers and owner.

Perform the following steps to modify the kernel parameters by using the /proc file system.

1. Log in as the root user.

2. Change to the /proc/sys/kernel directory.

3. Review the current semaphore parameter values in the sem file by using the cat or more utility. For example, using the cat utility, enter the following command:

   # cat sem
   
   

   The output lists, in order, the values for the SEMMSL, SEMMNS, SEMOPM, and SEMMNI parameters. The following example shows how the output appears:

   250 32000 32 128
   
   

   In the preceding output example, 250 is the value of the SEMMSL parameter, 32000 is the value of the SEMMNS parameter, 32 is the value of the SEMOPM parameter, and 128 is the value of the SEMMNI parameter.

4. Modify the parameter values by using the following command syntax:

   # echo SEMMSL_value SEMMNS_value SEMOPM_value SEMMNI_value > sem
   
   

   Replace the parameter variables with the values for your system in the order that they are entered in the preceding example. For example:

   # echo 100 32000 100 100 > sem
   
   

5. Review the current shared memory parameters by using the cat or more utility. For example, using the cat utility, enter the following command:

   # cat shared_memory_parameter
   
   

   In the preceding example, the variable shared_memory_parameter is either the SHMMAX or SHMMNI parameter. The parameter name must be entered in lowercase letters.

6. Modify the shared memory parameter by using the echo utility. For example, to modify the SHMMAX parameter, enter the following command:

   # echo 2147483648 > shmmax
   
   

7. Modify the shared memory parameter by using the echo utility. For example, to modify the SHMMNI parameter, enter the following command:

   # echo 4096 > shmmni
   
   

8. Modify the shared memory parameter by using the echo utility. For example, to modify the SHMALL parameter, enter the following command:

   # echo 2097152 > shmall
   
   

9. Write a script to initialize these values during system startup, and include the script in your system init files.

   
   

   See Also: Your system vendor's documentation for more information on script files and init files.

   
   

10. Set the File Handles by using ulimit -n and /proc/sys/fs/file-max.

    # echo 65536 > /proc/sys/fs/file-max
    ulimit -n 65536
    
    

11. Set the Sockets to /proc/sys/net/ipv4/ip_local_port_range

    # echo 1024 65000 > /proc/sys/net/ipv4/ip_local_port_change
    
    

12. Set the Process limit by using ulimit -u. This will give you the number of processes per user.

    ulimit -u 16384
    
    

The parameters in the following table are the minimum values required to run Oracle9i with a single-database instance on Linux.

For Solaris, use the ipcs command to obtain a list of the system's current shared memory and semaphore segments, and their identification number and owner.

Use a text editor such as vi to change the kernel parameter settings in the /etc/system file after making a backup copy. If you have previously changed your kernel for another program to levels equal to or higher than the levels Oracle9i requires, then do not change the settings. If the levels are too low, change them to levels at least as high as those in the table. If you change the settings, save the /etc/system file and restart the system.

The parameters in the following table are the minimum values to run Oracle9i with a single database instance on Solaris.

For Tru64, use a text editor such as vi to change the kernel parameter settings in the /etc/sysconfigtab file after making a backup copy. If you have previously changed your kernel for another program to levels equal to or higher than the levels Oracle9i requires, then do not touch the settings. If the levels are too low, change them to at least as high as those in the table. If you change the settings, save the /etc/sysconfigtab file and restart the system. For example, if you need to change your SHM_MAX, SHM_MNI, SHM_SEG, PER_PROC_STACK_SIZE, and PER_PROC_DATA_SIZE parameter settings, add the following lines to the /etc/sysconfigtab file:

ipc:  shm_max = 4278190080
      shm_mni = 256
      shm_seg = 128

proc: per_proc_stack_size = 33554432
      per_proc_data_size = 201326592

Refer to the following table to determine if your system shared memory and semaphore kernel parameters are set high enough for Oracle9i.

To determine the current kernel parameter settings, use the following command:

# /sbin/sysconfig -q ipc

The parameters in the following table are the recommended values to run Oracle9i with a single database instance on Tru64.

For all systems, including standalone or Real Application Clusters systems, you must set the following parameter in the /etc/sysconfigtab file:

vm:    new_wire_method = 0

If you are installing Oracle9i on systems where you expect to have SGAs (System Global Areas) greater than 4 GB in size, or on systems with many simultaneous (or near simultaneous) Oracle connects and disconnects, then Oracle Corporation recommends that you use different settings to enable the Granularity Hint (GH) regions (also called GH chunks) that such systems require.

The GH chunk region must be set large enough to hold all of the SGAs of concurrently running instances. The following section shows you how to determine the size of an individual SGA, and how to aggregate SGA sizes together to determine the proper settings for the GH chunks parameter.

To enable GH regions, you must know the total size of the SGA. The total size of the SGA is displayed on instance startup, as in the following example:

SQL> startup
ORACLE instance started.
Total System Global Area      4515625680 bytes
Fixed Size                        441040 bytes
Variable Size                  218103808 bytes
Database Buffers              4294967296 bytes
Redo Buffers                     2113536 bytes

You can also obtain SGA size using the following Query:

SQL> column totalsz format 999999999999
SQL> select sum(value) totalsz from v$sga

      TOTALSZ
-------------
4515625680

If more than one instance resides on your system, then you must add up the "Total System Global Area" numbers for all instances to set the gh_chunks parameter.

Use the following procedure to calculate the number for the gh_chunks parameter.

1. Determine the value for the adjusted SGA size for each instance with the following formula:

   adjusted_sga_size = "Total System Global Area" number + 8388608

2. As gh_chunks is allocated in 4 MB (4194304) units, the sum of the "Total System Global Area" numbers needs to be divided by 4 MB. Add up the adjusted_sga_size numbers for all instances and divide the sum by 4 MB (4194304) to find the value for sgavalue as represented in the following formula:

   sgavalue = (Sum of adjusted_sga_size numbers) / 4194304

3. Round up sgavalue to a whole number, and use it to make the following changes to the vm and ipc settings in the /etc/sysconfigtab file:

   vm:  gh_chunks = <sgavalue + 2>
   
   

When you have made these changes, restart the system so that they can take effect.

For example, if you had three instances on your system that each had a "Total System Global Area" value of 4515625680, then your calculations would be as follows:

Instance a: adjusted_sga_size a = 4515625680 + 8388608 = 4524014288

Instance b: adjusted_sga_size b = 4515625680 + 8388608 = 4524014288

Instance c: adjusted_sga_size c = 4515625680 + 8388608 = 4524014288

sgavalue = Sum of adjusted_sga_size a + b + c = 13572042864

value for gh_chunks = (13572042864 / 4194304) + 2

= 3235.8271 + 2

= 3237.8271

= 3238 (rounded to the nearest integer)

gh_chunks = 3238

If you use Real Application Clusters and 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 = 42240
       udp_sendspace = 42240

The Oracle9i installation requires at least two mount points:

• one for the software

• one or more for the database files

An Optimal Flexible Architecture (OFA)-compliant installation requires at least four mount points:

• one for the software

• three or more for the database files

All software and database mount point names use the syntax /pm, where p is a string constant and m is a unique fixed-length key (typically a two-digit number) used to distinguish each mount point. Examples: /u01 and /u02, or /disk01 and /disk02.

Oracle requires database administration groups to complete installation and to control database operations that are executed when a database is not mounted. Database administration groups enable operating system user authentication for Oracle administrative privileges, both for internal database accounts and for users to whom you may choose to grant privileges. Privileges are similar to those granted to INTERNAL in previous Oracle versions.

Oracle refers to these administrative UNIX groups as OSDBA, typically named dba, and OSOPER, typically named oper.

• You must create the OSDBA group. By default, the Oracle Universal Installer searches for a group called dba. If you choose to assign the OSDBA group privilege to a group with a name other than dba, then you are prompted for the group name during installation.

  Users that belong to the OSDBA group are granted SYSDBA privileges, which comprise all database system privileges. These privileges include the right to grant or revoke system privileges, as well as all other administrative privileges. OSDBA group membership must be granted only to database administrators.

  For HP users, the OSDBA group must be granted the HP system privileges RTSCHED, RTPRIO and MLOCK. For more information, refer to the Oracle9i Administrator's Reference Release 2 (9.2.0.1.0) for UNIX Systems.

• You may choose to create the OSOPER group.

  Users that belong to the OSOPER group are granted SYSOPER privileges, which comprise privileges required for basic system maintenance. SYSOPER privileges are a subset of those granted to SYSDBA. These include database startup and shutdown, and other privileges required for database operation. Users granted access to OSOPER group privileges may include application developers, application administrators, database users, and network administrators.

Table 2-5 lists utilities with which you can create the OSDBA group and other database administration groups. Use the utility that corresponds to your platform to create the OSDBA group.

Table 2-5 Utility to Add a Group

If you perform a Custom installation of Oracle9i database, or if the oracle account is not a member of a group called dba, then the Oracle Universal Installer prompts you to enter the group(s) you have created for these system privileges.

The ORAINVENTORY group owns the Oracle Universal Installer's oraInventory directory. It can be named anything, but typically it is named oinstall. The oraInventory is a repository of all installed Oracle products. The oraInventory is usually located in a directory named oraInventory, and its contents may only be modified by the Oracle Universal Installer. Any user who will be installing, removing, or patching Oracle products must be a member of the ORAINVENTORY group.

If you plan to have only one OSDBA group on a single system, then you can set the ORAINVENTORY group to the same name as the OSDBA group, which typically is dba. In this case, skip ahead to "Create a UNIX Account to Own Oracle Software ".

If you plan to have multiple installations on a single system and plan on having a unique OSDBA group for each install, then you will need a separate ORAINVENTORY group. The software owner, typically oracle, must have the ORAINVENTORY group as the primary group.

The following is a typical scenario for which a separate ORAINVENTORY group is needed:

• You have an operating system user named oracle1 with an OSDBA group of dba1.

• The oracle1 user works with a database named db11.

• You have another operating system user named oracle2 with an OSDBA group of dba2.

• The oracle2 user works with a database named db22.

• The db11 and db22 databases are installed in different ORACLE_HOME directories.

• The oracle1 user should have SYSDBA privileges in the db11 database, but should not have SYSDBA privileges in the db22 database.

• The oracle2 user should have SYSDBA privileges in the db22 database, but should not have SYSDBA privileges in the db11 database.

In this situation, it is important to remember that the oraInventory can only be updated by a single operating system group. In order to maintain this central repository of installed Oracle products, the oracle1 and oracle2 users must share a common group, which Oracle Corporation refers to as the ORAINVENTORY group.

In this scenario, by creating the ORAINVENTORY group and making it the primary group for both the oracle1 and oracle2 users, any new entries created by the Oracle Universal Installer for the oracle1 user can be read or updated by the Oracle Universal Installer for the oracle2 user.

Even though both oracle1 and oracle2 share Oracle software information in the ORAINVENTORY group, their different OSDBA group memberships preserve a separate database administrative access. oracle1 has dba1 as its secondary group. oracle2 has dba2 as its secondary group. The ORAINVENTORY group keeps the oraInventory repository of all Oracle executables and data files, but none of these files, except the oraInventory, are group writable. Only the owner of the executables or data files can modify them. oracle1 owns all files installed by oracle1. oracle2 owns all files installed by oracle2.

The oracle account is the UNIX user account that owns Oracle9i software after installation. You must run the Oracle Universal Installer with this user account. Table 2-6 describes the properties for the oracle account.

Table 2-6 oracle Account Properties

Table 2-7 lists the utilities to create the oracle account. Use the utility that corresponds to your platform.

Table 2-7 Utility to Add the oracle Account

Sites with multiple Oracle home directories on one system may install Oracle software either with the same oracle account or with different ones. Each oracle account must have the ORAINVENTORY group as its primary group.

If you will have multiple oracle accounts that must access the same ORAINVENTORY group as described in the preceding "Scenario for Creating an ORAINVENTORY Group", then verify that you have set up each account correctly. Table 2-8 describes the appropriate command for each platform.

Table 2-8 Command to Verify oracle Account Access to Primary Group

You should see the ORAINVENTORY group after gid=. You should see the OSDBA group in the groups= list. If you do not, ensure that both oracle1 and oracle2 accounts are listed in the /etc/groups file for the ORAINVENTORY group, that oracle1 is listed for the OSDBA1 group, and that oracle2 is listed for the OSDBA2 group.

The APACHE account is a UNIX user account that owns the Oracle HTTP Server after installation. If you use a default configuration (one that listens to ports lower than 1024, which are reserved for root), Oracle Corporation recommends that you set up a separate account to own Apache processes after installation for security reasons. This may affect the performance of other Oracle products.

Setting up the Oracle HTTP Server for Installation

During installation, the user account that owns the Oracle HTTP Server software must be a member of the ORAINVENTORY group in order to complete installation. The Oracle HTTP Server also must be started by the root user in order for ports reserved for root to be made available to the database and applications. For security reasons, Oracle Corporation recommends that provisions be made to change the Oracle HTTP Server group membership to a low-privileged group, and to transfer ownership of Oracle HTTP Server processes from root to a low-privileged account.

Improving Oracle HTTP Server Security After Installation

To improve security for database and application processes, create the Apache user. Configure the Oracle HTTP Server to transfer ownership of its processes from root to the Apache user by using the Apache configuration parameter user, which resets user ownership of processes spawned by Apache once the server starts. Assign ownership of listener and module actions for the Oracle HTTP Server to this user. This post-installation process is described in "Changing Group Membership of the Apache User".

Assign required access privileges to all Apache related module components to this user such that Apache and its modules can function as expected while minimizing security risks.

The Apache user should have minimal user privileges, and should not be a member of any groups whose files are not intended to be visible to the public. The nobody user account that many UNIX systems have can serve as a model for the Apache user. Be aware that all Web servers open to the public are at risk of being compromised, and take measures accordingly to minimize exposure to that risk.

Caution: Configuring the Apache user with OSDBA group or oracle user privileges compromises database security. If the Apache user needs additional rights to run programs, use the Apache suEXEC feature to obtain additional rights for the Apache user. If a user other than root starts the Oracle HTTP server, any scripts, servlets, or programs spawned by the Oracle HTTP server will have the same privileges as that user.

Table 2-9 describes the properties of the APACHE account.

Table 2-9 Properties of the Apache User for Installation

Table 2-10 lists the utilities to create the Apache user. Use the utility that corresponds to your platform.

Table 2-10 Utility to Add the Apache User

It is necessary to set the umask parameter to 022 for the oracle user to ensure that group and others have read and execute permissions, but not write permission, on the installed files.

1. Check the current setting by entering the following command:

   $ umask
   
   

2. If the umask command does not return the value 022, then set it for the oracle user by adding the following line to the.profile or.login file:

   umask 022
   
   

3. Execute the following command to verify the umask setting:

   $ umask 022
   

For Oracle9i 9.2.0.1.0 on AIX 5L, the function and performance benefits of the Oracle post-wait kernel extension are incorporated into the AIX kernel. Oracle9i 9.2.0.1.0 on AIX 5L does not require the Oracle post-wait kernel extension to be loaded.

For Oracle9i 9.2.0.1.0 on AIX 4.3.3, the following remarks about the kernel extension still apply. The Oracle post-wait kernel extension for AIX implements an optimized mechanism of inter-process communications without the overhead of signal handlers or semaphores. The Oracle post-wait kernel extension is loaded into the kernel at system startup and remains loaded as long as the system is running. It is used by all the Oracle instances running on the system.

The following section explains how to install and debug the kernel extension. If you have already run rootpre.sh from the latest version of the Oracle RDBMS, skip the installation step.

The Oracle post-wait kernel extension is installed in the /etc directory by the rootpre.sh script prior to the installation of the Oracle RDBMS. The kernel extension consists of two files: pw-syscall and loadext. pw-syscall is the actual kernel extension. loadext loads, unloads, queries, or gets the version of the kernel extension. It is also path-sensitive. rootpre.sh script copies a 64-bit enabled pw-syscall to the /etc directory. This kernel extension supports both 32-bit and 64-bit Oracle instances.

Perform the following pre-installation steps to install Oracle Real Application Clusters on AIX.

1. Configure and start HACMP/ES before running rootpre.sh script to install Oracle Real Application Clusters.

2. Add oracle user to hagsuser group. This is required by non root users to use the PSSP and HACMP group service.

Setup Tasks to Perform as the oracle User

Log in as the oracle account and perform the following tasks as necessary:

• Set Environment Variables

• Update the Environment for Current Session

It is necessary to set the DISPLAY and PATH environment variables before running the Oracle Universal Installer. Other environmental variables such as the documentation directory or executables path may also be set before running the Oracle Universal Installer.

Table 2-11 provides a brief summary of the variables listed in this section. See each variable's entry in this section for instructions on setting the variable appropriately.

Table 2-11 Environment Variable Summary

DISPLAY

The DISPLAY variable specifies the name, server number, and screen number of the system where the Oracle Universal Installer displays. On the system where you will run Oracle Universal Installer, set the DISPLAY variable to include the system name or IP address, the X server value, and the screen value used by your workstation. If you are unsure of the value to which you should set the X server and screen, use 0 (zero) for both. Do not use the hostname or IP address of the system where the software is being installed unless you are performing the installation from that system's X Window console.

If you get an Xlib error similar to "Failed to connect to server," "Connection refused by server," or "Can't open display" when starting the Oracle Universal Installer, you must run one of the following shell commands on your X workstation.

For the Bourne or Korn shells:

In the session on your workstation, enter the following:

$ xhost +server_name

From your workstation where you will run the installation, connect to the server to which you intend to install Oracle9i and enter the following:

$ DISPLAY=workstation_name:0.0
$ export DISPLAY

For the C shell:

In the session on your workstation, enter the following:

% xhost +server_name

Connect from your workstation where you will run the installation, to the server on which you intend to install Oracle9i database. Enter the following:

% setenv DISPLAY workstation_name:0.0

Note: If you are using a PC X server, then refer to your PC X server documentation for instructions on how to configure the PC X server to allow a remote X client to connect to the server.

PATH

The PATH variable specifies the shell's search path for executables. Set the shell's search path to include the information in the following table.

Table 2-12 lists the paths for the PATH variable that correspond to your platform.

Table 2-12 Shell Search Paths

ORA_NLS33

The ORA_NLS33 variable specifies the directory location of the *.nlb files. The *.nlb files define languages, territories, character sets, and linguistic sorting orders. Set this variable only if the *.nlb files are in a non-default location, which is $ORACLE_HOME/ocommon/nls/admin/data.

See Also: Oracle9i Globalization and National Language Support Guide for more information on languages, territories, character sets and sorting orders.

ORACLE_BASE

The ORACLE_BASE variable specifies the directory at the top of the Oracle software and administrative file structure. The recommended value for an OFA-compliant configuration is /software_mount_point/app/oracle. For example:

/u01/app/oracle

Note: You must set the ORACLE_BASE variable even if you are not using an OFA-compliant configuration.

ORACLE_DOC

The ORACLE_DOC variable specifies the directory to install the online documentation.

See Also: "Accessing Installed Documentation" for more information on how to determine where documentation will be installed if the variable is not set.

ORACLE_HOME

The ORACLE_HOME variable specifies the directory containing the Oracle software for a particular release. Ensure that the value of ORACLE_HOME points to a directory that does not contain any Oracle software from an earlier release.

The Optimal Flexible Architecture recommended value is:

$ORACLE_BASE/product/release

For example:

/u01/app/oracle/product/9.2.0.1.0

ORACLE_SID

The ORACLE_SID variable specifies the System Identifier (SID) to be used by the Oracle server instance during installation. If you plan on creating a database during installation, then you have the option of setting ORACLE_SID to the value of the sid. The Oracle Universal Installer will prompt you to confirm this value.

Use a text editor to set the environment variables in the.profile or.login file of the oracle account. You can update the environment in the current shell session before beginning installation by using the appropriate shell command.

For the Bourne or Korn shells:

On the server where the Oracle database will be installed, enter the following commands:

$ cd
$ . $HOME/.profile

For the C shell:

On the server where the Oracle database will be installed, enter the following commands:

% cd
% source $HOME/.login

Setup Tasks for Oracle Products

Before you can install Oracle9i software, pre-installation steps must be completed for the following products:

• Oracle9i Components

• Oracle Real Application Clusters

• Precompilers and Tools

• Network and System Management Products

$ /usr/sbin/cmruncl

Unaligned access pid=12227

<unaligned> va=11ffffb84

pc=1200010e0 ra=120001060 type=ldq

$ lsnrctl status listener_name

$ lsnrctl stop listener_name

$ ftp remote_server_name
ftp> put test_filename
ftp> get test_filename
ftp> bye