• When installing Red Hat Linux Fedora Core 2, I install ALL components. (Everything). This makes it easier than trying to troubleshoot missing software components.

• As of March 26, 2004, Oracle includes the Oracle9i database software with the 9.2.0.4.0 patchset already included. This will save considerable time since the patchset does not have to be downloaded and installed. We will, however, be applying the 9.2.0.5.0 patchset.

• Although it is not required, it is recommend to apply the 9.2.0.5.0 patchset.

• The post installation section includes steps for configuring the Oracle Networking files, configuring the database to start and stop when the machine is cycled, and other miscellaneous tasks.

• Finally, at the end of this article, we will be creating an Oracle 9.2.0.5.0 database named ORA920 using supplied scripts.

• Installing Oracle9i requires a minimum of 512MB of memory.
  (An inadequate amount of swap during the installation will cause the Oracle Universal Installer to either "hang" or "die")

• To check the amount of memory / swap you have allocated, type either:

  # free

  - OR -

  # cat /proc/swaps

  - OR -

  # cat /proc/meminfo | grep MemTotal

• If you have less than 512MB of memory (between your RAM and SWAP), you can add temporary swap space by creating a temporary swap file. This way you do not have to use a raw device or even more drastic, rebuild your system.

  As root, make a file that will act as additional swap space, let's say about 300MB:
  # dd if=/dev/zero of=tempswap bs=1k count=300000

  Now we should change the file permissions:
  # chmod 600 tempswap

  Finally we format the "partition" as swap and add it to the swap space:
  # mke2fs tempswap
  # mkswap tempswap
  # swapon tempswap
  

Oracle uses shared memory in UNIX to hold its Shared Global Area (SGA). This is an area of memory within the Oracle instance that is shared by all Oracle backup and foreground processes. It is important to size the SGA to efficiently hold the database buffer cache, shared pool, redo log buffer as well as other shared Oracle memory structures. Inadequate sizing of the SGA can have a dramatic decrease in performance of the database.

To determine all shared memory limits you can use the ipcs command. The following example shows the values of my shared memory limits on a fresh RedHat Linux install using the defaults:

# ipcs -lm

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

SHMMAX

The SHMMAX parameter is used to define the maximum size (in bytes) for a shared memory segment and should be set large enough for the largest SGA size. If the SHMMAX is set incorrectly (too low), it is possible that the Oracle SGA (which is held in shared segments) may be limited in size. An inadequate SHMMAX setting would result in the following:

ORA-27123: unable to attach to shared memory segment

You can determine the value of SHMMAX by performing the following:

# cat /proc/sys/kernel/shmmax
33554432

As you can see from the output above, the default value for SHMMAX is 32MB. This is often too small to configure the Oracle SGA. I generally set the SHMMAX parameter to 2GB.

NOTE: With a 32-bit Linux operating system, the default maximum size of the SGA is 1.7GB. This is the reason I will often set the SHMMAX parameter to 2GB since it requires a larger value for SHMMAX. On a 32-bit Linux operating system, without Physical Address Extension (PAE), the physical memory is divided into a 3GB user space and a 1GB kernel space. It is therefore possible to create a 2.7GB SGA, but you will need make several changes at the Linux operating system level by changing the mapped base. In the case of a 2.7GB SGA, you would want to set the SHMMAX parameter to 3GB. Keep in mind that the maximum value of the SHMMAX parameter is 4GB.

To change the value SHMMAX, you can use either of the following three methods:

• This is method I use most often. This method sets the SHMMAX on startup by inserting the following kernel parameter in the /etc/sysctl.conf startup file:

  # echo "kernel.shmmax=2147483648" >> /etc/sysctl.conf

• If you wanted to dynamically alter the value of SHMMAX without rebooting the machine, you can make this change directly to the /proc file system. This command can be made permanent by putting it into the /etc/rc.local startup file:

  # echo "2147483648" > /proc/sys/kernel/shmmax

• You can also use the sysctl command to change the value of SHMMAX:

  # sysctl -w kernel.shmmax=2147483648

SHMMNI

We now look at the SHMMNI parameters. This kernel parameter is used to set the maximum number of shared memory segments system wide. The default value for this parameter is 4096. This value is sufficient and typically does not need to be changed.

You can determine the value of SHMMNI by performing the following:

# cat /proc/sys/kernel/shmmni
4096

SHMALL

Finally, we look at the SHMALL shared memory kernel parameter. This parameter controls the total amount of shared memory (in pages) that can be used at one time on the system. In short, the value of this parameter should always be at least:

ceil(SHMMAX/PAGE_SIZE)

The default size of SHMALL is 2097152 and can be queried using the following command:

# cat /proc/sys/kernel/shmall
2097152

From the above output, the total amount of shared memory (in bytes) that can be used at one time on the system is:

SM = (SHMALL * PAGE_SIZE)
   = 2097152 * 4096
   = 8,589,934,592 bytes

The default setting for SHMALL should be adequate for our Oracle installation.

NOTE: The page size in Red Hat Linux on the i386 platform is 4096 bytes. You can, however, use bigpages which supports the configuration of larger memory page sizes.

To determine all semaphore limits, use the following:

# ipcs -ls

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

# cat /proc/sys/kernel/sem
250     32000   32      128

SEMMSL

The SEMMSL kernel parameter is used to control the maximum number of semaphores per semaphore set.

Oracle recommends setting SEMMSL to the largest PROCESS instance parameter setting in the init.ora file for all databases hosted on the Linux system plus 10. Also, Oracle recommends setting the SEMMSL to a value of no less than 100.

SEMMNI

The SEMMNI kernel parameter is used to control the maximum number of semaphore sets on the entire Linux system.

Oracle recommends setting the SEMMNI to a value of no less than 100.

SEMMNS

The SEMMNS kernel parameter is used to control the maximum number of semaphores (not semaphore sets) on the entire Linux system.

Oracle recommends setting the SEMMNS to the sum of the PROCESSES instance parameter setting for each database on the system, adding the largest PROCESSES twice, and then finally adding 10 for each Oracle database on the system. To summarize:

SEMMNS =   sum of PROCESSES setting for each database on the system
         + ( 2 * [largest PROCESSES setting])
         + (10 * [number of databases on system]

To determine the maximum number of semaphores that can be allocated on a Linux system, use the following calculation. It will be the lesser of:

SEMMNS  -or-  (SEMMSL * SEMMNI)

SEMOPM

The SEMOPM kernel parameter is used to control the number of semaphore operations that can be performed per semop system call.

The semop system call (function) provides the ability to do operations for multiple semaphores with one semop system call. A semaphore set can have the maximum number of SEMMSL semaphores per semaphore set and is therefore recommended to set SEMOPM equal to SEMMSL.

Oracle recommends setting the SEMOPM to a value of no less than 100.

Setting Semaphore Kernel Parameters

Finally, we see how to set all semaphore parameters using several methods. In the following, the only parameter I care about changing (raising) is SEMOPM. All other default settings should be sufficient for our example installation.

• This is method I use most often. This method sets all semaphore kernel parameters on startup by inserting the following kernel parameter in the /etc/sysctl.conf startup file:

  # echo "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf

• If you wanted to dynamically alter the value of all semaphore kernel parameters without rebooting the machine, you can make this change directly to the /proc file system. This command can be made permanent by putting it into the /etc/rc.local startup file:

  # echo "250 32000 100 128" > /proc/sys/kernel/sem

• You can also use the sysctl command to change the value of all semaphore settings:

  # sysctl -w kernel.sem="250 32000 100 128"

Use the following command to determine the maximum number of file handles for the entire system:

# cat /proc/sys/fs/file-max
103062

Oracle recommends that the file handles for the entire system be set to at least 65536. In most cases, the default for Red Hat Linux is 103062. I have seen others (Red Hat Linux AS 2.1, Fedora Core 1, and Red Hat version 9) that will only default to 32768. If this is the case, you will want to increase this value to at least 65536.

• This is method I use most often. This method sets the maximum number of file handles (using the kernel parameter file-max) on startup by inserting the following kernel parameter in the /etc/sysctl.conf startup file:

  # echo "fs.file-max=65536" >> /etc/sysctl.conf

• If you wanted to dynamically alter the value of all semaphore kernel parameters without rebooting the machine, you can make this change directly to the /proc file system. This command can be made permanent by putting it into the /etc/rc.local startup file:

  # echo "65536" > /proc/sys/fs/file-max

• You can also use the sysctl command to change the maximum number of file handles:

  # sysctl -w fs.file-max=65536

NOTE: It is also possible to query the current usage of file handles using the following command: # cat /proc/sys/fs/file-nr 1140 0 103062 In the above example output, here is an explanation of the three values from the file-nr command: Total number of allocated file handles. Total number of file handles currently being used. Maximum number of file handles that can be allocated. This is essentially the value of file-max - (see above).

NOTE: If you need to increase the value in /proc/sys/fs/file-max, then make sure that the ulimit is set properly. Usually for 2.4.20 it is set to unlimited. Verify the ulimit setting my issuing the ulimit command: # ulimit unlimited

1. Login as the root user id.

   % su -

2. Create directories.

   # mkdir -p /u01/app/oracle
   # mkdir -p /u03/app/oradata
   # mkdir -p /u04/app/oradata
   # mkdir -p /u05/app/oradata
   # mkdir -p /u06/app/oradata

3. Create the UNIX Group for the Oracle User Id.

   # groupadd -g 115 dba

4. Create the UNIX User for the Oracle Software.

   # useradd -u 173 -c "Oracle Software Owner" -d /u01/app/oracle -g "dba" -m -s /bin/bash oracle
   # passwd oracle
   Changing password for user oracle.
   New UNIX password: ************
   BAD PASSWORD: it is based on a dictionary word
   Retype new UNIX password: ************
   passwd: all authentication tokens updated successfully.

5. Change ownership of all Oracle Directories to the Oracle UNIX User.

   # chown -R oracle:dba /u01
   # chown -R oracle:dba /u03
   # chown -R oracle:dba /u04
   # chown -R oracle:dba /u05
   # chown -R oracle:dba /u06

6. Oracle Environment Variable Settings

   NOTE: Ensure to set the environment variable: LD_ASSUME_KERNEL=2.4.1 Failing to set the LD_ASSUME_KERNEL parameter will cause the Oracle Universal Installer to hang!

7. Verify all mount points. Please keep in mind that all of the following mount points can simply be directories if you only have one hard drive. For our installation, we will be using four mount points (or directories) as follows:
   • /u01 : The Oracle database software will be installed to /u01/app/oracle.

   • /u03 : This mount point will contain the physical Oracle files:
     • Control File 1
     • Online Redo Log File - Group 1 / Member 1
     • Online Redo Log File - Group 2 / Member 1
     • Online Redo Log File - Group 3 / Member 1

   • /u04 : This mount point will contain the physical Oracle files:
     • Control File 2
     • Online Redo Log File - Group 1 / Member 2
     • Online Redo Log File - Group 2 / Member 2
     • Online Redo Log File - Group 3 / Member 2

   • /u05 : This mount point will contain the physical Oracle files:
     • Control File 3
     • Online Redo Log File - Group 1 / Member 3
     • Online Redo Log File - Group 2 / Member 3
     • Online Redo Log File - Group 3 / Member 3

   • /u06 : This mount point will contain the all physical Oracle data files.
     • This will be one large RAID 0 stripe for all Oracle data files.
     • All tablespaces including System, UNDO, Temporary, Data, and Index.

You can use the following command to query these shell limits:

# ulimit -a

core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16383
virtual memory        (kbytes, -v) unlimited

Maximum Number of Open File Descriptors for Shell Session

Let's first talk about the maximum number of open file descriptors for a user's shell session.

NOTE: Make sure that throughout this section, that you are logged in as the oracle user account since this is the shell account we want to test!

Ok, you are first going to tell me, "But I've already altered my Linux environment by setting the system wide kernel parameter /proc/sys/fs/file-max". Yes, this is correct, but there is still a per user limit on the number of open file descriptors. This typically defaults to 1024. To check that, use the following command:

% su - oracle
% ulimit -n
1024

If you wanted to change the maximum number of open file descriptors for a user's shell session, you could edit the /etc/security/limits.conf as the root account. For your Linux system, you would add the following lines:

oracle           soft    nofile          4096
oracle           hard    nofile          101062

The first line above sets the soft limit, which is the number of files handles (or open files) that the Oracle user will have after logging in to the shell account. The hard limit defines the maximum number of file handles (or open files) are possible for the user's shell account. If the oracle user account starts to recieve error messages about running out of file handles, then number of file handles should be increased for the oracle using the user should increase the number of file handles using the hard limit setting. You can increase the value of this parameter to 101062 for the current session by using the following:

% ulimit -n 101062

Keep in mind that the above command will only effect the current shell session. If you were to log out and log back in, the value would be set back to its default for that shell session.

NOTE: Although you can set the soft and hard file limits higher, it is critical to understand to never set the hard limit for nofile for your shell account equal to /proc/sys/fs/file-max. If you were to do this, your shell session could use up all of the file descriptors for the entire Linux system, which means that the entire Linux system would run out of file descriptors. At this point, you would not be able to initiate any new logins since the system would not be able to open any PAM modules, which are required for login. Notice that I set my hard limit to 101062 and not 103062. In short, I am leaving 2000 spare!

We're not totally done yet. We still need to ensure that pam_limits is configured in the /etc/pam.d/system-auth file. The steps defined below sould already be performed with a normal Red Hat Linux installation, but should still be validated!

The PAM module will read the /etc/security/limits.conf file. You should have an entry in the /etc/pam.d/system-auth file as follows:

session     required      /lib/security/$ISA/pam_limits.so

I typically validate that my /etc/pam.d/system-auth file has the following two entries:

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so

Finally, let's test our new settings for the maximum number of open file descriptors for the oracle shell session. Logout and log back in as the oracle user account then run the following commands.

Let's first check all current soft shell limits:

$ ulimit -Sa
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 4096
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16383
virtual memory        (kbytes, -v) unlimited

Finally, let's check all current hard shell limits:

$ ulimit -Ha
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 101062
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) unlimited
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16383
virtual memory        (kbytes, -v) unlimited

The soft limit is now set to 4096 while the hard limit is now set to 101062.

NOTE: There may be times when you cannot get access to the root user account to change the /etc/security/limits.conf file. You can set this value in the user's login script for the shell as follows: su - oracle cat >> ~oracle/.bash_profile << EOF ulimit -n 101062 EOF

NOTE: For this section, I used the BASH shell. The session values will not always be the same for other shells.

Maximum Number of Processes for Shell Session

This section is very similar to the previous section, "Maximum Number of Open File Descriptors for Shell Session" and deals with the same concept of soft limits and hard limits as well as configuring pam_limits. For most default Red Hat Linux installations, you will not need to be concerned with the maximum number of user processes as this value is generally high enough!

NOTE: For this section, I used the BASH shell. The session values will not always be the same for other shells.

Let's start by querying the current limit of the maximum number of processes for the oracle user:

% su - oracle
% ulimit -u
16383

If you wanted to change the soft and hard limits for the maximum number of processes for the oracle user, (and for that matter, all users), you could edit the /etc/security/limits.conf as the root account. For your Linux system, you would add the following lines:

oracle           soft    nproc          2047
oracle           hard    nproc          16384

NOTE: There may be times when you cannot get access to the root user account to change the /etc/security/limits.conf file. You can set this value in the user's login script for the shell as follows: su - oracle cat >> ~oracle/.bash_profile << EOF ulimit -u 16384 EOF

Miscellaneous Notes

To check all current soft shell limits, enter the following command:

$ ulimit -Sa
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 4096
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16383
virtual memory        (kbytes, -v) unlimited

To check maximum hard limits, enter the following command:

$ ulimit -Ha
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 101062
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) unlimited
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16383
virtual memory        (kbytes, -v) unlimited

The file (blocks) value should be multiplied by 512 to obtain the maximum file size imposed by the shell. A value of unlimited is the operating system default and typically has a maximum value of 1 TB.

NOTE: Oracle9i Release 2 (9.2.0) includes native support for files greater than 2 GB. Check your shell to determine whether it will impose a limit.

All of these packages will need to be installed as the root user:

From Fedora Core 2 / Disk #1

1. Set your DISPLAY variable to a valid X Windows display.

   % DISPLAY=<Any X-Windows Host>:0.0
   % export DISPLAY
   

   NOTE: If you forgot to set the DISPLAY environment variable and you get the following error:

   Xlib: connection to ":0.0" refused by server
   Xlib: Client is not authorized to connect to Server
   

   you will then need to execute the following command to get "runInstaller" working again:
   % rm -rf /tmp/OraInstall

   If you don't do this, the Installer will hang without giving any error messages. Also make sure that "runInstaller" has stopped running in the background. If not, kill it.

2. Change directory to the Oracle installation files you downloaded and extracted. Then run: runInstaller.

   $ su - oracle
   $ cd orainstall/Disk1
   $ ./runInstaller
   Initializing Java Virtual Machine from /tmp/OraInstall2004-05-02_08-45-13PM/jre/bin/java. Please wait...

   Screen Name	Response
   Welcome Screen:	Click "Next"
   Inventory Location:	Click "OK"
   UNIX Group Name:	Use "dba"
   Root Script Window:	Open another window, login as the root userid, and run "/tmp/orainstRoot.sh". When the script has completed, return to the dialog from the Oracle Installer and hit Continue.
   File Locations:	Leave the "Source Path" at its default setting. For the Destination name, I like to use "OraHome920". You can leave the Destination path at it's default value which should be "/u01/app/oracle/product/9.2.0".
   Available Products:	Select "Oracle9i Database 9.2.0.4.0" and click "Next"
   Installation Types:	Select "Enterprise Edition (2.84GB)" and click "Next"
   Database Configuration:	Select "Software Only" and click "Next"
   Summary:	Click "Install"

3. Running root.sh script.

   When the "Link" phase is complete, you will be prompted to run the $ORACLE_HOME/root.sh script as the "root" user account.

4. Shutdown any started Oracle processes

   The Oracle Universal Installer will succeed in starting some Oracle programs, in particular the Oracle HTTP Server (Apache), the Oracle Intelligent Agent, and possibly the Orcle TNS Listener. Make sure all programs are shutdown before attempting to continue in installing the Oracle 9.2.0.5.0 patchset:

   % $ORACLE_HOME/Apache/Apache/bin/apachectl stop
   
   % agentctl stop
   
   % lsnrctl stop

NOTE: The details and instructions for applying the 9.2.0.5.0 patchset in this article is not absolutely necessary. I provide it here simply as a convenience for those how do want to apply the latest patchset.

The 9.2.0.5.0 patchset can be downloaded from Oracle Metalink:

Patch Number:	3501955
Description:	ORACLE 9i DATABASE SERVER RELEASE 2 - PATCH SET 4 VERSION 9.2.0.5.0
Product:	Oracle Database Family
Release:	Oracle 9.2.0.5
Select a Platform or Language:	Linux x86
Last Updated:	26-MAR-2004
Size:	313M (328923077 bytes)

Use the following steps to install the Oracle10g Universal Installer and then the Oracle 9.2.0.5.0 patchset.

1. To start, let's unpack the Oracle 9.2.0.5.0 to a temporary directory:

   % cd orapatch
   % unzip p3501955_9205_LINUX.zip
   % cpio -idmv < 9205_lnx32_release.cpio

2. Next, we need to install the Oracle10g Universal Installer into the same $ORACLE_HOME we used to install the Oracle9i database software.

   NOTE: Using the old Universal Installer that was used to install the Oracle9i database software, (OUI release 2.2), cannot be used to install the 9.2.0.5.0 patchset and higher!

   Starting with the Oracle 9.2.0.5.0 patchset, Oracle requires the use of the Oracle10g Universal Installer to apply the 9.2.0.5.0 patchset and to perform all subsequent maintenance operations on the Oracle software $ORACLE_HOME.

   Let's get this thing started by installing the Oracle10g Universal Installer. This must be done by running the runInstaller that is included with the 9.2.0.5.0 patchset we extracted in the above step:

   % cd orapatch/Disk1
   % ./runInstaller -ignoreSysPrereqs
   Starting Oracle Universal Installer...
   
   Checking installer requirements...
   
   Checking operating system version: must be redhat-2.1, UnitedLinux-1.0, redhat-3, SuSE-7 or SuSE-8
                                         Failed <<<<
   
   
   >>> Ignoring required pre-requisite failures. Continuing...
   
   Preparing to launch Oracle Universal Installer from /tmp/OraInstall2004-08-30_07-48-15PM. Please wait ...
   Oracle Universal Installer, Version
    10.1.0.2.0 Production
   Copyright (C) 1999, 2004, Oracle. All rights reserved.

   Use the following options in the Oracle Universal Installer to install the Oracle10g OUI:

   Screen Name	Response
   Welcome Screen:	Click "Next"
   File Locations:	The "Source Path" should be pointing to the products.xml file by default. For the Destination name, choose the same one you created when installing the Oracle9i software. The name we used in this article was "OraHome920" and the destination path should be "/u01/app/oracle/product/9.2.0".
   Select a Product to Install:	Select "Oracle Universal Installer 10.1.0.2.0" and click "Next"
   Summary:	Click "Install"

3. Exit from the Oracle Universal Installer.

4. Correct the runInstaller symbolic link bug. (Bug 3560961)

   After the installation of Oracle10g Universal Installer, there is a bug that does NOT update the $ORACLE_HOME/bin/runInstaller symbolic link to point to the new 10g installation location. Since the symbolic link does not get updated, the runInstaller command still points to the old installer (2.2) and will be run instead of the new 10g installer.

   To correct this, you will need to manually update the $ORACLE_HOME/bin/runInstaller symbolic link:

   % cd $ORACLE_HOME/bin
   % ln -s -f $ORACLE_HOME/oui/bin/runInstaller.sh runInstaller

5. We now install the Oracle 9.2.0.5.0 patchset by executing the newly installed 10g Universal Installer:

   % cd
   % runInstaller -ignoreSysPrereqs
   Starting Oracle Universal Installer...
   
   Checking installer requirements...
   
   Checking operating system version: must be redhat-2.1, UnitedLinux-1.0, redhat-3, SuSE-7 or SuSE-8
                                         Failed <<<<
   
   
   >>> Ignoring required pre-requisite failures. Continuing...
   
   Preparing to launch Oracle Universal Installer from /tmp/OraInstall2004-08-30_07-59-30PM. Please wait ...
   Oracle Universal Installer, Version
    10.1.0.2.0 Production
   Copyright (C) 1999, 2004, Oracle. All rights reserved.

   Here is an overview of the selections I made while performing the 9.2.0.5.0 patchset install:

   Screen Name	Response
   Welcome Screen:	Click "Next"
   File Locations:	The "Source Path" should be pointing to the products.xml file by default. For the Destination name, choose the same one you created when installing the Oracle9i software. The name we used in this article was "OraHome920" and the destination path should be "/u01/app/oracle/product/9.2.0".
   Select a Product to Install:	Select "Oracle 9iR2 Patchsets 9.2.0.5.0" and click "Next"
   Summary:	Click "Install"

6. Running root.sh script.

   When the Link phase is complete, you will be prompted to run the $ORACLE_HOME/root.sh script as the "root" user account. Go ahead and run the root.sh script.

7. Exit Universal Installer

   Exit from the Universal Installer and continue on to the Post Installation section of this article.

1. Configuring Oracle Networking Files:

   I already included sample configuration files (contained in the oracle_920_installation_files_linux.tar file) that can be simply copied to their proper location and started. Change to the oracle HOME directory and copy the files as follows:

   % cd
   % cd oracle_920_installation_files_linux
   % cp ldap.ora $ORACLE_HOME/network/admin/
   % cp tnsnames.ora $ORACLE_HOME/network/admin/
   % cp sqlnet.ora $ORACLE_HOME/network/admin/
   % cp listener.ora $ORACLE_HOME/network/admin/
   
   % cd
   % lsnrctl start

2. Update /etc/oratab:

   The dbora script (below) relies on an entry in the /etc/oratab. Perform the following actions as the oracle user account:

   % echo "ORA920:/u01/app/oracle/product/9.2.0:Y" >> /etc/oratab

3. Configuring Startup / Shutdown Scripts:

   Also included in the oracle_920_installation_files_linux.tar file is a script called dbora. This script can be used by the init process to startup and shutdown the database when the machine is cycled. The following tasks will need to be performed by the root user account:

   % su -
   # cp /u01/app/oracle/oracle_920_installation_files_linux/dbora /etc/init.d
   
   # chmod 755 /etc/init.d/dbora
   
   # ln -s /etc/init.d/dbora /etc/rc3.d/S99dbora
   # ln -s /etc/init.d/dbora /etc/rc4.d/S99dbora
   # ln -s /etc/init.d/dbora /etc/rc5.d/S99dbora
   # ln -s /etc/init.d/dbora /etc/rc0.d/K10dbora
   # ln -s /etc/init.d/dbora /etc/rc6.d/K10dbora

% su - oracle
% cd admin/ORA920/create
% ./RUN_CRDB.sh

$ telnet linux3
...
Fedora Core release 2 (Tettnang)
Kernel 2.6.5-1.358 on an i686
login: oracle
Password: xxxxxx
.bash_profile executed
[oracle@linux3 oracle]$ cd admin/ORA920/create
[oracle@linux3 create]$ tail -f crdb.log