DBA Tips Archive for Oracle

  


Install Oracle9i R2 on Linux - (Fedora Core 2)

by Jeff Hunter, Sr. Database Administrator


Contents

  1. Overview
  2. Swap Space Considerations
  3. Configuring Shared Memory
  4. Configuring Semaphores
  5. Configuring File Handles
  6. Create Oracle Account and Directories
  7. Configuring the Oracle Environment
  8. Configuring Oracle User Shell Limits
  9. Downloading / Unpacking the Oracle9i Installation Files
  10. Update Red Hat Linux System - (Oracle Metalink Note: 252217.1)
  11. Install the Oracle 9.2.0.4.0 Database Software
  12. Install the Oracle 9.2.0.5.0 Patchset
  13. Post Installation Steps
  14. Creating the Oracle Database
  15. About the Author


Overview

This article is a comprehensive guide for installing Oracle9i Release 2 (9.2.0.4.0) on the Red Hat Linux Fedora Core 2 operating environment. Also included in this article is a detailed overview for applying the Oracle9i (9.2.0.5.0) patchset. Keep in mind the following assumptions throughout this article:


Swap Space Considerations

Ensure enough swap space is available.


Configuring Shared Memory

The Oracle database uses shared memory in UNIX to allow processes to access common data structures and data. These data structures and data are placed in a shared memory segment to allow processes the fastest form of Interprocess Communications (IPC) available. The speed is primarily a result of processes not needing to copy data between each other to share common data and structures - relieving the kernel from having to get involved.

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
Let's continue this section with an overview of the parameters that are responsible for configuring the shared memory settings in Linux.

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.


Configuring Semaphores

Now that we have configured our shared memory settings, it is time to take care of configuring our semaphores. A semaphore can be thought of as a counter that is used to control access to a shared resource. Semaphores provide low level synchronization between processes (or threads within a process) so that only one process (or thread) has access to the shared segment, thereby ensureing the integrity of that shared resource. When an application requests semaphores, it does so using "sets".

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
You can also use the following command:
# 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"


Configuring File Handles

When configuring our Linux database server, it is critical to ensure that the maximum number of file handles is large enough. The setting for file handles designate the number of open files that you can have on the entire Linux system.

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.

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


Create Oracle Account and Directories

Now let's create the Oracle UNIX account all all required directories:
  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.


Configuring the Oracle Environment

After configuring the Linux operating environment, it is time to setup the Oracle UNIX User ID for the installation of the Oracle database software. Keep in mind that the following steps need to be performed by the oracle user id.

Before delving into the details for configuring the Oracle User ID, I packaged an archive of shell scripts and configuration files to assist with the Oracle preparation and installation. You should download the archive "oracle_920_installation_files_linux.tar" as the Oracle User ID and place it in his HOME directory.

  1. Login as the oracle user id.
    % su - oracle

  2. Unpackage the contents of the oracle_920_installation_files_linux.tar archive. After extracting the archive, you will have a new directory called oracle_920_installation_files_linux that contains all required files. The following set of commands descibe how to extract the file and where to copy/extract all required files:
    $ id
    uid=173(oracle) gid=115(dba) groups=115(dba)
    
    $ pwd
    /u01/app/oracle
    
    $ tar xvf oracle_920_installation_files_linux.tar
    oracle_920_installation_files_linux/
    oracle_920_installation_files_linux/admin.tar
    oracle_920_installation_files_linux/common.tar
    oracle_920_installation_files_linux/dbora
    oracle_920_installation_files_linux/dbshut
    oracle_920_installation_files_linux/.bash_profile
    oracle_920_installation_files_linux/dbstart
    oracle_920_installation_files_linux/ldap.ora
    oracle_920_installation_files_linux/listener.ora
    oracle_920_installation_files_linux/sqlnet.ora
    oracle_920_installation_files_linux/tnsnames.ora
    oracle_920_installation_files_linux/crontabORA920.txt
    
    $ cp oracle_920_installation_files_linux/.bash_profile ~/.bash_profile
    
    $ tar xvf oracle_920_installation_files_linux/admin.tar
    
    $ tar xvf oracle_920_installation_files_linux/common.tar
    
    $ . ~/.bash_profile
    .bash_profile executed
    $


Configuring Oracle User Shell Limits

Many of the Linux shells (including BASH) implement certain controls over certain critical resources like the number of file descriptors that can be opened and the maximum number of processes available to a user's session. In most cases, you will not need to alter any of these shell limits, but you find yourself getting errors when creating or maintaining the Oracle database, you may want to read through this section.

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.


Downloading / Unpacking the Oracle9i Installation Files


Update Red Hat Linux System - (Oracle Metalink Note: 252217.1)

The following RPMs, all of which are available on the Red Hat Fedora Core 2 CDs, will need to be updated as per the steps described in Metalink Note: 252217.1 - "Requirements for Installing Oracle 9iR2 on RHEL3".

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

From Fedora Core 2 / Disk #1

# cd /mnt/cdrom/Fedora/RPMS
# rpm -Uvh libpng-1.2.2-22.i386.rpm
From Fedora Core 2 / Disk #2
# cd /mnt/cdrom/Fedora/RPMS
# rpm -Uvh gnome-libs-1.4.1.2.90-40.i386.rpm
From Fedora Core 2 / Disk #3
# cd /mnt/cdrom/Fedora/RPMS
# rpm -Uvh compat-libstdc++-7.3-2.96.126.i386.rpm
# rpm -Uvh compat-libstdc++-devel-7.3-2.96.126.i386.rpm
# rpm -Uvh compat-db-4.1.25-2.1.i386.rpm
# rpm -Uvh compat-gcc-7.3-2.96.126.i386.rpm
# rpm -Uvh compat-gcc-c++-7.3-2.96.126.i386.rpm
# rpm -Uvh openmotif21-2.1.30-9.i386.rpm
# rpm -Uvh pdksh-5.2.14-24.i386.rpm
From Fedora Core 2 / Disk #4
# cd /mnt/cdrom/Fedora/RPMS
# rpm -Uvh sysstat-5.0.1-2.i386.rpm
Set gcc296 and g++296 in PATH
Put gcc296 and g++296 first in $PATH variable by creating the following symbolic links:
# mv /usr/bin/gcc /usr/bin/gcc323
# mv /usr/bin/g++ /usr/bin/g++323
# ln -s /usr/bin/gcc296 /usr/bin/gcc
# ln -s /usr/bin/g++296 /usr/bin/g++
Check hostname
Make sure the hostname command returns a fully qualified host name by amending the /etc/hosts file if necessary:
# hostname
Install the 3006854 patch:
The Oracle / Linux Patch 3006854 can be downloaded here.
# unzip p3006854_9204_LINUX.zip
# cd 3006854
# sh rhel3_pre_install.sh


Install the Oracle 9.2.0.4.0 Database Software

As the "oracle" user account:

  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


Install the Oracle 9.2.0.5.0 Patchset

Once you have completed installing of the Oracle9i (9.2.0.4.0) database software, you should now apply the 9.2.0.5.0 patchset.

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.


Post Installation Steps

After applying the Oracle 9.2.0.5.0 patchset, we should perform several miscellaneous tasks like configuring the Oracle Networking files and setting up startup and shutdown scripts for then the machine is cycled.
  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


Creating the Oracle Database

Finally, let's create an Oracle9i database. This can be done using scripts that I already included with the oracle_920_installation_files_linux.tar download. The scripts are included in the ~oracle/admin/ORA920/create directory. To create the database, perform the following steps:
% su - oracle
% cd admin/ORA920/create
% ./RUN_CRDB.sh
After starting the RUN_CRDB.sh, there will be no screen activity until the database creation is complete. You can, however, bring up a new console window to the Linux databse server as the oracle user account, navigate to the same directory you started the database creation from, and tail the crdb.log log file.
$ 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



About the Author

Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.



Copyright (c) 1998-2014 Jeffrey M. Hunter. All rights reserved.

All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at jhunter@idevelopment.info.

I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.

Last modified on
Monday, 02-Jan-2012 15:08:54 EST
Page Count: 431720