Installing Oracle Database 10g on Linux x86

by John Smiley

*Updated for RHEL4 and SLES9*

Contents
Overview
Part I: Installing Linux
    RHEL4
    RHEL3
    RHEL2.1
    SLES9
    SLES8
Part II: Configuring Linux for Oracle
    Verify System Requirements
    Create Directories
    Create the Oracle Groups and User Account
    Configure Linux Kernel Parameters
    Set Shell Limits for the oracle User
    Avoid the Bug! (SLES8 Only)
    Environment Variables for the oracle User
Part III: Installing Oracle
    Install the Software
Part IV: Configuring Storage
    Filesystems
    Automatic Storage Management
Conclusion
Appendix
Tips and Hints
Oracle Errors and Problems
Part V: Tuning Linux for Oracle

Overview

The five Linux distributions certified for Oracle Database 10g covered are:

Part I: Installing Linux

This guide assumes a server with the following hardware:

The disks are configured so that each SCSI host adapter is connected to one 9GB disk and three 36GB disks.

Note that although this is far from a "beefy" setup, much of what this guide covers can be accomplished with even less horsepower. All that is necessary for a basic database install is a single CPU, 512MB of RAM, and one disk drive (IDE, SCSI, or FireWire) with at least 6.5GB of free space.

RHEL4

Oracle Database 10g is certified to run the base release of RHEL4 (Advanced Server and Enterprise Server) without updates. (Free evaluation copies of RHEL4 are available for download.) If you have update CDs, you can use the boot CD from the update instead of the boot CD from the base release to automatically apply all updates during the installation. All updates from Red Hat are supported by Oracle.

The easiest and fastest way to apply the updates for a fresh install of Linux is to perform the install by using the update CDs. If Linux is already installed or you don't have the updates on CDs, they can be applied through RHN. Because this guide is designed for a fresh Linux install, you'll use the update CDs.

  1. Boot the server using the first CD.
  2. The boot screen appears with the boot: prompt at the bottom of the screen.
  3. Language Selection
  4. Keyboard Configuration
  5. Welcome Screen
  6. Disk Partitioning Setup
  7. Boot Loader Configuration
  8. Network Configuration
  9. Firewall Configuration
  10. Additional Language Support
  11. Time Zone Selection
  12. Set Root Password
  13. Package Installation Defaults
  14. Package Group Selection
  15. Installing Packages
  16. Congratulations
  17. The system automatically reboots and presents a new welcome screen.
  18. License Agreement
  19. Date and Time
  20. Display
  21. Red Hat Login
  22. System User
  23. Additional CDs
  24. Finish Setup
  25. A graphical login screen appears.
  26. Congratulations! Your RHEL4 software is now installed.

Verifying Your Installation

If you've completed the steps above, you should have all the packages and updates required for Oracle Database 10g . However, you can take the steps below to verify your installation.
Required kernel version: 2.6.9-5.EL (This is the kernel version shipped with the base release of RHEL4. This kernel, or any of the kernels supplied in updates, works with Oracle Database 10g .)

Check your kernel version by running the following command: 

uname -r
Ex:
# uname -r
2.6.9-5.ELsmp
Other required package versions  To see which versions of these packages are installed on your system, run the following command as root: 
rpm -q gcc make binutils openmotif setarch compat-db


Ex:  
# rpm -q gcc make binutils openmotif setarch compat-db
gcc-3.4.3-9.EL4
make-3.80-5
binutils-2.15.92.0.2-10.EL4
setarch-1.6-1
compat-db-4.1.25-9

Install the following packages:

# From RedHat AS4 Disk 2
cd /media/cdrom/RedHat/RPMS
rpm -Uvh setarch-1.6-1.i386.rpm
rpm -Uvh compat-libstdc++-33-3.2.3-47.3.i386.rpm

# From RedHat AS4 Disk 3
cd /media/cdrom/RedHat/RPMS
rpm -Uvh openmotif-2.2.3-6.RHEL4.2.i386.rpm
rpm -Uvh compat-db-4.1.25-9.i386.rpm

# From RedHat AS4 Disk 4
cd /media/cdrom/RedHat/RPMS
rpm -Uvh compat-gcc-32-3.2.3-47.3.i386.rpm
rpm -Uvh compat-gcc-32-c++-3.2.3-47.3.i386.rpm


RHEL3

Oracle Database 10g is certified to run the base release of Red Hat Enterprise Linux 3 (Advanced Server and Enterprise Server) without updates. If you have update CDs, you can use the boot CD from the update instead of the boot CD from the base release to automatically apply all updates during the installation. All updates from Red Hat are supported by Oracle.

  1. Boot the server using the first CD.
  2. The boot screen appears with the boot: prompt at the bottom of the screen.
  3. Language Selection
  4. Keyboard Configuration
  5. Welcome Screen
  6. Mouse Configuration
  7. Installation Type
  8. Disk Partitioning Setup
  9. Boot Loader Configuration
  10. Network Configuration
  11. Firewall Configuration
  12. Additional Language Support
  13. Time Zone Selection
  14. Set Root Password
  15. Package Group Selection
  16. About to Install
  17. Installing Packages
  18. Graphical Interface (X) Configuration
  19. Monitor Configuration
  20. Customize Graphical Configuration
  21. Congratulations
  22. The system automatically reboots and presents a new welcome screen.
  23. License Agreement
  24. Date and Time
  25. User Account
  26. Red Hat Network
  27. Additional CDs
  28. Finish Setup
  29. A graphical login screen appears.
  30. Congratulations! Your Linux software is now installed.
Verifying Your Installation

If you've completed the steps above, you should have all the packages and updates required for Oracle Database 10g. However, you can take the steps below to verify your installation.

Required kernel version: 2.4.21-4.EL (This is the kernel version shipped with the base release of RHEL3. This kernel, or any of the kernels supplied in updates, works with Oracle Database 10g.)

Check your kernel version by running the following command: 

uname -r

Ex:
# uname -r
2.4.21-4.0.1.ELsmp
Other required package versions (or later): To see which versions of these packages are installed on your system, run the following command as root:
rpm -q gcc make binutils openmotif setarch compat-db compat-gcc \
     compat-gcc-c++ compat-libstdc++ compat-libstdc++-devel

Ex:
# rpm -q gcc make binutils openmotif setarch compat-db compat-gcc \
>      openmotif compat-gcc-c++ compat-libstdc++ compat-libstdc++-devel
gcc-3.2.3-20
make-3.79.1-17
binutils-2.14.90.0.4-26
openmotif-2.2.2-16
setarch-1.3-1
package compat-db is not installed
compat-gcc-7.3-2.96.122
compat-gcc-c++-7.3-2.96.122
compat-libstdc++-7.3-2.96.122
compat-libstdc++-devel-7.3-2.96.122

Installing compat-db
Insert CD2 of the original Red Hat Enterprise Linux media. (This package has not been updated as of Update 2 and is found only on the original media.)
The CD mounts automatically.
Run the following command as root: 

rpm -ivh /mnt/cdrom/RedHat/RPMS/compat-db-4.0.14-5.i386.rpm

Ex:
# rpm -ivh /mnt/cdrom/RedHat/RPMS/compat-db-4.0.14-5.i386.rpm
Preparing...         ########################################### [100%]
   1:compat-db       ########################################### [100%]


You can install the rest of packages just inserting the CD's, go to:
/mnt/cdrom/RedHat/RPMS
From there double click on the packages that you need

RHEL2.1

Oracle Database 10g is certified to run on Red Hat Enterprise Linux 2.1 (Advanced Server and Enterprise Server) with Update 3 or higher. Updates are available from the Red Hat Network (RHN) and can be downloaded as ISO files for creating CDs or as individual package updates.

The easiest and fastest way to apply the updates for a fresh install of Linux is to perform the install by using the update CDs. If Linux is already installed or you don't have the updates on CDs, they can be applied through RHN. Because this guide is designed for a fresh Linux install, you'll use the update CDs.

  1. Boot the server using the first CD in the set of update CDs.
  2. The boot screen appears with the boot: prompt at the bottom of the screen.
  3. Language Selection
  4. Keyboard Configuration
  5. Mouse Configuration
  6. Installation Type
  7. Disk Partitioning Setup
  8. Boot Loader Configuration
  9. Boot Loader Password Configuration
  10. Network Configuration
  11. Firewall Configuration
  12. Additional Language Support
  13. Time Zone Selection
  14. Account Configuration
  15. Package Group Selection
  16. Unresolved Dependencies
  17. Graphical Interface (X) Configuration
  18. Preparing to install
  19. Installing packages
  20. Boot disk creation
  21. Monitor Configuration
  22. Congratulations
The system automatically reboots and presents a graphical login screen. If you have performed the installation with the base product CDs rather than the update CDs, you will have to apply the updates through RHN before proceeding.

Verifying Your Installation

If you've completed the steps above, you should have all the packages and updates required for Oracle Database 10g. However, you can take the steps below to verify your installation.

Required kernel version: 2.4.9-e.25 (or later)

Check your kernel version by running the following command: 

uname -r

Ex:
# uname -r
2.4.9-e.27smp
Other required package versions (or later): To see which versions of these packages are installed on your system, run the following command: 
rpm -q gcc make binutils openmotif glibc

Ex:  
# rpm -q gcc make binutils openmotif glibc
gcc-2.96-118.7.2
make-3.79.1-8
binutils-2.11.90.0.8-12
openmotif-2.1.30-11
glibc-2.2.4-32.8
If any of the package versions on your system are missing or the versions are earlier than those specified above, you can download and install the updates from the Red Hat Network.

SLES9

Oracle Database 10g is certified to run on the base release of SLES9. Service Packs and package updates are available from Novell, either on CDs or online via its support portal. In this guide, we will install on the SLES9 base release.

  1. Boot the server, using the SLES9 CD.
  2. The Novell SLES installation screen appears.
  3. Language Selection
  4. Installation Settings
  5. Partitioning
  6. Software
  7. Time Zone
  8. Click on Accept.
  9. A warning box appears. Click on Yes, install when ready to proceed.
  10. Change CDs as prompted by the installer.
  11. Confirm Hardware Detection
  12. Password for "root." the system administrator.
  13. Configure your network interface(s), and click on Next when ready to proceed.
  14. Test Internet Connection
  15. Service Configuration
  16. User Authentication Method
  17. Add a New Local User
  18. Release Notes
  19. Hardware Configuration
  20. Installation Completed
  21. Congratulations! Your SLES9 software is now installed.
Verifying Your Installation

If you've completed the steps above, you should have all the packages and updates required for Oracle Database 10g. However, you can take the steps below to verify your installation.

Required kernel version: 2.6.5-7.5 (or later)

Check your kernel version by running the following command: 

uname -r

Ex:
# uname -r
2.6.5-7.97-smp
Other required package versions (or later): To see which versions of these packages are installed on your system, run the following command as root:

rpm -q gcc gcc-c++ glibc libaio libaio-devel make openmotif-libs

Ex:  
# rpm -q gcc gcc-c++ glibc libaio libaio-devel make openmotif-libs
gcc-3.3.3-43.24
gcc-c++-3.3.3-43.24
glibc-2.3.3-98.28
libaio-0.3.98-18.3
libaio-devel-0.3.98-18.3
make-3.80-184.1
openmotif-libs-2.2.2-519.1
If any of the package versions on your system are missing or the versions are earlier than those specified above, you can download and install the updates from the Novell SUSE Linux Portal.

SLES8

Oracle Database 10g is certified to run on Novell SUSE Linux Enterprise Server (SLES) 8 and SLES-9. Service Packs and package updates are available from Novell, either on CDs or online via its support portal. In this guide, we will install on SLES8 with Service Pack 3 from CDs.

  1. Boot the server, using the SLES8 CD.
  2. The SUSE Linux Enterprise Server installation screen appears.
  3. Language Selection
  4. Installation Settings
  5. Partitioning
  6. Software
  7. Time Zone
  8. Click on Accept.
  9. A warning box appears. Click on Yes, install when ready to proceed.
  10. Change CDs as prompted by the installer.
  11. When the software has been installed, a window will appear advising that the base system has been successfully installed.
  12. The system reboots.
  13. Enter a password for root, and repeat to confirm.
  14. Create an account for yourself. Do not create the oracle account at this time; we'll do that later.
  15. Desktop Settings
  16. A warning window appears regarding automatic detection of local printers.
  17. Configure your network interface(s), and click on Next when ready to proceed.
  18. A graphical login screen appears.
  19. Now you need to install Service Pack 3. Log in as yourself.
  20. Insert the update CD, and click on Patch CD Update.
  21. Start YaST2, SUSE's system administration tool.
  22. The YaST Online Update window appears.
  23. A window appears with a list of patch updates.
  24. A window appears advising to restart the online update.
  25. A window appears, stating that the installation was successful.
  26. In the YaST Online Update window, click on Finish.
  27. In the YaST Control Center window, click on Close.
  28. Repeat steps 21 and 22.
  29. A window appears with a list of patch updates.
  30. A window appears, reporting that the installation was successful.
  31. On the YaST Online Update screen, click on Next.
  32. In the YaST Control Center, click on Close.
  33. Log out.
  34. Remove the update CD.
  35. Reboot the system.
  36. Congratulations! Your Linux software is now installed.
Verifying Your Installation

If you've completed the steps above, you should have all the packages and updates required for Oracle Database 10g. However, you can take the steps below to verify your installation.

Required kernel version: 2.4.21-138 (or later)

Check your kernel version by running the following command: 

uname -r

Ex:
# uname -r
k_smp-2.4.21-138
Other required package versions (or later): To see which versions of these packages are installed on your system, run the following command as root:
rpm -q gcc make binutils openmotif

Ex:  
# rpm rpm -q gcc make binutils openmotif
gcc-3.2.2-38
make-3.79.1-407
binutils-2.12.90.0.15-50
openmotif-2.2.2-124
If any of the package versions on your system are missing or the versions are earlier than those specified above, you can download and install the updates from the SUSE Linux Portal.

Part II: Configuring Linux for Oracle

Verifying System Requirements

To verify that your system meets the minimum requirements for an Oracle 10g database, log in as root and run the commands below.

To check the size of physical memory, execute: 
grep MemTotal /proc/meminfo
To check the size of swap space, execute: 
grep SwapTotal /proc/meminfo
You also can add temporary swap space to your system by creating a temporary swap file instead of using a raw device. Here is the procedure: 
su - root
dd if=/dev/zero of=tmpswap bs=1k count=900000
chmod 600 tmpswap
mkswap tmpswap
swapon tmpswap
To disable the temporary swap space execute the following commands: 
su - root
swapoff tmpswap
rm tmpswap

According to Oracle's documentation, the Oracle Universal Installer (OUI) requires up to 400 MB of free space in the /tmp directory. But OUI checks if /tmp is only greater than 80 MB.

To check the space in /tmp, run: 
$ df /tmp
If you do not have enough space in the /tmp filesystem, you can temporarily create a tmp directory in another filesystem. Here is how you can do this: 
su - root
mkdir /<AnotherFilesystem>/tmp
chown root.root /<AnotherFilesystem>/tmp
chmod 1777 /<AnotherFilesystem>/tmp
export TEMP=/<AnotherFilesystem>           # used by Oracle
export TMPDIR=/<AnotherFilesystem>         # used by Linux programs like the linker "ld"
When you are done with the Oracle installation, shutdown Oracle and remove the temporary /tmp directory: 
su - root
rmdir /<AnotherFilesystem>/tmp
unset TEMP

unset TMPDIR

Create the Oracle Groups and User Account

To create the oracle account and groups, execute the following commands: 
su - root
groupadd dba          # group of users to be granted SYSDBA system privilege
groupadd oinstall     # group owner of Oracle files
useradd -c "Oracle software owner" -g oinstall -G dba oracle
passwd oracle

Create Directories

Now create directories to store the Oracle 10g software and the database files. This guide adheres to the Optimal Flexible Architecture (OFA) for the naming conventions used in creating the directory structure. For more information on OFA standards, see Appendix D of the Oracle Database 10g Installation Guide for UNIX Systems.

The following assumes that the directories are being created in the root filesystem. This is done for the sake of simplicity and is not recommended as a general practice. These directories would normally be created as separate filesystems.

Issue the following commands as root: 

mkdir -p /u01/app/oracle
mkdir -p /u02/oradata
chown -R oracle:oinstall /u01/app/oracle /u02/oradata
chmod -R 775 /u01/app/oracle /u02/oradata


Configuring the Linux Kernel Parameters

The Linux kernel is a wonderful thing. Unlike most other *NIX systems, Linux allows modification of most kernel parameters while the system is up and running. There's no need to reboot the system after making kernel parameter changes. Oracle Database 10g requires the kernel parameter settings shown below. The values given are minimums, so if your system uses a larger value, don't change it. 

shmmax  = 2147483648     (To verify, execute: cat /proc/sys/kernel/shmmax)
shmmni  = 4096           (To verify, execute: cat /proc/sys/kernel/shmmni)
shmall  = 2097152        (To verify, execute: cat /proc/sys/kernel/shmall)   (for 10g R1)
shmmin  = 1              (To verify, execute: ipcs -lm |grep "min seg size")
shmseg  = 10             (It's hardcoded in the kernel - the default is much higher)
semmsl  = 250            (To verify, execute: cat /proc/sys/kernel/sem | awk '{print $1}')
semmns  = 32000          (To verify, execute: cat /proc/sys/kernel/sem | awk '{print $2}')
semopm  = 100            (To verify, execute: cat /proc/sys/kernel/sem | awk '{print $3}')
semmni  = 128            (To verify, execute: cat /proc/sys/kernel/sem | awk '{print $4}')
file-max = 65536         (To verify, execute: cat /proc/sys/fs/file-max)
ip_local_port_range = 1024 65000 (To verify, execute: cat /proc/sys/net/ipv4/ip_local_port_range)

If you're following along and have just installed Linux, the kernel parameters will all be at their default values and you can just cut and paste the following commands while logged in as root. 

cat >> /etc/sysctl.conf <<EOF
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144 
net.core.rmem_max = 262144 
net.core.wmem_default = 262144 
net.core.wmem_max = 262144
EOF

sysctl -p



Network Setttings
It is also recommended to Adjust Network Setttings in particular for RAC systems.
Ensure to set these network parameters for 10g R2 since the OUI checks these!
Oracle now uses UDP as the default protocol on Linux for interprocess communication, such as cache fusion buffer transfers between the instances.
It is strongly suggested to adjust the default and maximum send buffer size (SO_SNDBUF socket option) to 256 KB, and the default and maximum receive buffer size (SO_RCVBUF socket option) to 256 KB. The receive buffers are used by TCP and UDP to hold received data until is is read by the application. The receive buffer cannot overflow because the peer is not allowed to send data beyond the buffer size window. This means that datagrams will be discarded if they don't fit in the socket receive buffer. This could cause the sender to overwhelm the receiver.

The default and maximum window size can be changed in the proc file system without reboot: 
su - root
sysctl -w net.core.rmem_default=262144  # Default setting in bytes of the socket receive buffer
sysctl -w net.core.wmem_default=262144  # Default setting in bytes of the socket send buffer
sysctl -w net.core.rmem_max=262144      # Maximum socket receive buffer size which may be set by using the SO_RCVBUF socket option
sysctl -w net.core.wmem_max=262144      # Maximum socket send buffer size which may be set by using the SO_SNDBUF socket option
To make the change permanent, add the following lines to the /etc/sysctl.conf file, which is used during the boot process: 
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144

Verify your settings!!!

If any of the parameters on your system are set lower than those shown, edit the /etc/sysctl.conf file and add or change the parameters. When you're finished, run the following command to activate the changes: 

sysctl -p

For all Novell SUSE Linux releases, use the following: 

				   /sbin/chkconfig boot.sysctl on


Setting Shell Limits for the oracle User

Oracle recommends setting limits on the number of processes and open files each Linux account may use. To make these changes, cut and paste the following commands as root: 

cat >> /etc/security/limits.conf <<EOF
oracle               soft    nproc   2047
oracle               hard    nproc   16384
oracle               soft    nofile  4096
oracle               hard    nofile  65536
EOF

cat >> /etc/pam.d/login <<EOF
session    required     /lib/security/pam_limits.so
EOF

For RHEL 2.1 and 3, use the following: 

cat >> /etc/profile <<EOF
if [ \$USER = "oracle" ]; then  
   if [ \$SHELL = "/bin/ksh" ]; then
       ulimit -p 16384
       ulimit -n 65536
   else
       ulimit -u 16384 -n 65536
   fi
   umask 022
fi
EOF

cat >> /etc/csh.login <<EOF
if ( \$USER == "oracle" ) then
   limit maxproc 16384
   limit descriptors 65536
   umask 022
endif
EOF

For SLES8, use the following: 

cat >> /etc/profile.local <<EOF
if [ \$USER = "oracle" ]; then  
   if [ \$SHELL = "/bin/ksh" ]; then
       ulimit -p 16384
       ulimit -n 65536
   else
       ulimit -u 16384 -n 65536
   fi
   umask 022
fi
EOF

cat >> /etc/csh.login.local <<EOF
if ( \$USER == "oracle" ) then
   limit maxproc 16384
   limit descriptors 65536
   umask 022
endif
EOF

Avoid the Bug! (Novell SUSE Linux releases only)

There is a bug in the installation of Oracle Enterprise Manager 10g on SLES8 and SLES9 that causes it to fail due to required ports that are reserved in /etc/services. The OEM DBConsole needs port 1830, and in SUSE environments this port is already reserved in /etc/services. This bug is documented in MetaLink as bug# 3513603.

To avoid problems during the installation, log in as root and comment out the lines for ports 1830 through 1849 in the /etc/services file prior to installing the Oracle Database 10g software. (Note: It's probably a good idea to reboot the server at this point, to ensure that the above changes are in effect.)

Environment Variables for the oracle User

If you have more than one Oracle product or database on the same server, the ORACLE_HOME, ORACLE_SID, and PATH variables may change. The ORACLE_BASE variable should not change and can be set in your login profile if you want. Oracle provides a utility, called oraenv, for setting the remaining variables.

Log in as oracle and add ORACLE_BASE to your login profile by adding the following line to your .bash_profile or .profile (bash or ksh): 

# Oracle Settings
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=XXXXXX

This change will take effect the next time you log in to the oracle account. To make the changes active for the current session, simply run the command from the command line.

Part III: Installing Oracle

Oracle Database 10g can be downloaded from OTN. Oracle offers a development and testing license free of charge. However, no support is provided and the license does not permit production use. A full description of the license agreement is available on OTN. The easiest way to make the Oracle Database 10g distribution media available on your server is to download them directly to the server.

Installing Oracle10g on a Remote Linux Server
If you don't install Oracle on your local system but on a remote server, then you need to relink X to your local desktop. The easiest way to do this is to use the "X11 forwarding" feature of ssh. This means that you don't have to run xhost and set the DISPLAY environment variable.
Here is an example how to make use of the "X11 forward" feature of ssh. Simply run the following command from your local desktop: 

$ ssh -X oracle@oracle_remote_server_name
Now when you try to run any GUI tool on the remote server, it will automatically be relinked to your local desktop. If this is not working, verify that the ForwardX11 setting is not set to "no" in /etc/ssh/ssh_config on the remote server: 
su - root
# grep ForwardX11 /etc/ssh/ssh_config | grep -v "^#"
        ForwardX11 yes
#
Working with the Installed Files
Compute a cyclic redundancy check (CRC) checksum for the downloaded files and
compare the checksum numbers against the numbers posted on OTN's website. For example:
cksum ship.db.lnx32.cpio.gz

Uncompress the downloaded file(s):
gunzip ship.db.lnx32.cpio.gz

Unpack ship.db.lnx32.cpio:
$ cpio -idmv < ship.db.lnx32.cpio

Install the Software

As the oracle user, Change directory to Disk1.
$ cd Disk1

Start the Oracle Universal Installer. 

$ ./runInstaller

  1. Welcome
  2. Specify Inventory Directory and Credentials
  3. If this is the first time Oracle has been installed on this machine, you will get a pop-up window indicating that the orainstRoot.sh script needs to be run as root. Log in as root, cd to the directory specified in the window, and execute the script before proceeding.
  4. Specify File Locations
  5. Select Installation Type
  6. Product-specific Prerequisite Checks
  7. Select Database Configuration
  8. Specify Database Configuration Options
  9. Select Database Management Option
  10. Specify Database File Storage Option
  11. Specify Backup and Recovery Options
  12. Specify Database Schema Passwords
  13. Summary
  14. Install
  15. End of Installation
  16. Congratulations! Your new Oracle 10g database is up and ready for use.

Post Installation Tasks
Edit the /etc/oratab file setting the restart flag for each instance to 'Y' and remove empty lines:
XXX:/u01/app/oracle/product/10.1.0/db_1:Y

Create a file called /etc/init.d/dbora containing the following:
#!/bin/sh
# description: Oracle auto start-stop script.
# chkconfig: - 20 80
#
# Set ORA_HOME to be equivalent to the $ORACLE_HOME
# from which you wish to execute dbstart and dbshut;
#
# Set ORA_OWNER to the user id of the owner of the
# Oracle database in ORA_HOME.
ORA_HOME=/u01/app/oracle/product/10.1.0/db_1
ORA_OWNER=oracle
if [ ! -f $ORA_HOME/bin/dbstart ]
then
    echo "Oracle startup: cannot start"
    exit
fi
case "$1" in
    'start')
        # Start the Oracle databases:
        # The following command assumes that the oracle login
        # will not prompt the user for any values
        su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl start"
        su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
        ;;
    'stop')
        # Stop the Oracle databases:
        # The following command assumes that the oracle login
        # will not prompt the user for any values
        su - $ORA_OWNER -c $ORA_HOME/bin/dbshut
        su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl stop"
        ;;
esac

Use chmod to set the privileges to 750:
chmod 750 /etc/init.d/dbora

Link the file into the appropriate run-level script directories:
ln -s /etc/init.d/dbora /etc/rc0.d/K10dbora
ln -s /etc/init.d/dbora /etc/rc3.d/S99dbora

Associate the dbora service with the appropriate run levels:
chkconfig --level 345 dbora on

Part IV: Configuring Storage

The database we created in Part III used a single filesystem (/u02/oradata) for disk storage. However, there are several ways to configure storage for an Oracle database.
Part IV explores other methods of configuring disk storage for this database. In particular, it describes creating additional filesystems and using Automatic Storage Management (ASM).

Filesystems

Filesystems are the most widely used means of storing data file, redo logs, and control files for Oracle databases. Filesystems are easy to implement and require no third-party software to administer. In most cases, filesystems are created during the initial installation of Linux. However, there are times when a new filesystem must be created after the initial installation, such as when a new disk drive is being installed. This section describes building a new filesystem and using it in an Oracle database. Unless otherwise noted, all commands must be run as root.

Partition the Disk

You must have an empty disk partition to create the filesystem. If you already have an empty disk partition available, skip to the next step. The following shows an example of creating a new partition for a Linux filesystem. (WARNING: Improperly partitioning a disk is one of the surest and fastest ways to wipe out everything on your hard disk. If you are unsure how to proceed, stop and get help, or you will risk losing data.)
This example uses /dev/sdb (an empty SCSI disk with no existing partitions) to create a single partition for the entire disk (36 GB).

# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 4427.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdb: 255 heads, 63 sectors, 4427 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-4427, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-4427, default 4427):
Using default value 4427

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.

Now verify the new partition: 

Ex:
# fdisk /dev/sdb

The number of cylinders for this disk is set to 4427.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdb: 255 heads, 63 sectors, 4427 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/sdb1             1      4427  35559846   83  Linux

Command (m for help): q

Create the Filesystem

Use ext3 to create this new filesystem. Other filesystems work just as well, but ext3 offers the fastest recovery time in the event of a system crash. 

Ex:
# mke2fs -j /dev/sdb1
mke2fs 1.26 (3-Feb-2002)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
4447744 inodes, 8889961 blocks
444498 blocks (5.00%) reserved for the super user
First data block=0
272 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
        2654208, 4096000, 7962624

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Create the Mount Point

A filesystem must have a mount point, which is simply an empty directory where the new filesystem "attaches" to the system's directory tree. Mount points should be given names consistent with the Oracle Flexible Architecture (OFA) standard. For more information on OFA standards, see Appendix D of the Oracle 10g Database Installation Guide.
Because you have already used the /u01 and /u02 directory names in Part I, use /u03 for this example. 

Ex:
# mkdir /u03

Add the New Filesystem to /etc/fstab

So that the new filesystem will be mounted automatically when the system boots, you need to add a line to the /etc/fstab file that describes the new filesystem and where to mount it. Add a line similar to the one below to /etc/fstab, using a text editor. 

/dev/sdb1         /u03           ext3    defaults       1 1

Mount the New Filesystem

Mounting the filesystem makes it available for use. Until the filesystem is mounted, files cannot be stored in it. Use the following commands to mount the filesystem and verify that it is available. 

mount /u03
df -h /u03

Ex:
# mount /u03
# df -h /u03
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             33G   33M  31G   1%   /u03

Create Oracle Directories and Set Permissions

Now you create a directory to store your Oracle files. The directory name used in the example follows the OFA standard naming convention for a database with ORACLE_SID=demo1. 

mkdir -p /u03/oradata/demo1
chown -R oracle:oinstall /u03/oradata
chmod -R 775 /u03/oradata

Create a New Tablespace in the New Filesystem

The new filesystem is ready for use. Next you create a new tablespace in the filesystem to store your database objects. Connect to the database as the SYSTEM user, and execute the CREATE TABLESPACE statement, specifying the data file in the new filesystem. 

Ex:
create tablespace data1 datafile '/u03/oradata/demo1/data1_01.dbf' size 100M
extent management local
segment space management auto;

Automatic Storage Management (ASM)

I've saved the best for last.  ASM is a fantastic new feature in Oracle Database 10g that provides the services of a filesystem, logical volume manager, and software RAID in a platform-independent manner. ASM can stripe and mirror your disks, allow disks to be added or removed while the database is under load, and automatically balance I/O to remove "hot spots." It also supports direct and asynchronous I/O and implements the Oracle Data Manager API (simplified I/O system call interface) introduced in Oracle9i.
ASM is not a general-purpose filesystem and can be used only for Oracle data files, redo logs, and control files. Files in ASM can be created and named automatically by the database (by use of the Oracle Managed Files feature) or manually by the DBA. Because the files stored in ASM are not accessible to the operating system, the only way to perform backup and recovery operations on databases that use ASM files is through Recovery Manager (RMAN).
ASM is implemented as a separate Oracle instance that must be up if other databases are to be able to access it. On Linux the OCSSD service (installed by default by the Oracle Universal Installer) must be running to allow use of ASM. Memory requirements for ASM are light: only 64 MB for most systems.

More information HERE

Installing ASM
On Linux platforms, ASM can use raw devices or devices managed via the ASMLib interface. Oracle recommends ASMLib over raw devices, for ease-of-use and performance reasons. ASMLib is available for free download from OTN. This section walks through the process of configuring a simple ASM instance by using ASMLib and building a database that uses ASM for disk storage.

Determine Which Version of ASMLib You Need

ASMLib is delivered as a set of three Linux packages:

Each Linux distribution has its own set of ASMLib packages, and within each distribution, each kernel version has a corresponding oracleasm package. The following paragraphs describe how to determine which set of packages you need.

First, determine which kernel you are using by logging in as root and running the following command: 

uname -rm

Ex:
# uname -rm
2.4.9-e.27smp i686

The example shows that this is a 2.4.9 kernel for an SMP (multiprocessor) box using Intel i686 CPUs.

Use this information to find the correct ASMLib packages on OTN:

  1. Point your Web browser to http://www.oracle.com/technology/tech/linux/asmlib
  2. Select the link for your version of Linux.
  3. Download the oracleasmlib and oracleasm-support packages for your version of Linux
  4. Download the oracleasm package corresponding to your kernel. In the example above, the oracleasm-2.4.9-e-smp-1.0.0-1.i686.rpm package is downloaded.

    Next, install the packages by executing the following command as root: 

    rpm -Uvh oracleasm-kernel_version-asmlib_version.cpu_type.rpm \
    oracleasmlib-asmlib_version.cpu_type.rpm \
    oracleasm-support-asmlib_version.cpu_type.rpm

    Ex:
    # rpm -Uvh \
    > oracleasm-2.4.9-e-smp-1.0.0-1.i686.rpm \
    > oracleasmlib-1.0.0-1.i386.rpm \
    > oracleasm-support-1.0.0-1.i386.rpm
    Preparing...                #################################### [100%]
       1:oracleasm-support      #################################### [ 33%]
       2:oracleasm-2.4.9-e-smp  #################################### [ 66%]
    Linking module oracleasm.o into the module path [  OK  ]
       3:oracleasmlib           #################################### [100%]
    5.

Configuring ASMLib
Before using ASMLib, you must run a configuration script to prepare the driver. Run the following command as root, and answer the prompts as shown in the example below. 

# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting <ENTER> without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface []: dba
Start Oracle ASM library driver on boot (y/n) [n]: y
Fix permissions of Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration            [  OK  ]
Creating /dev/oracleasm mount point                        [  OK  ]
Loading module "oracleasm"                                 [  OK  ]
Mounting ASMlib driver filesystem                          [  OK  ]
Scanning system for ASM disks                              [  OK  ]

Now enable the ASMLib driver as shown below. 

# /etc/init.d/oracleasm enable
Writing Oracle ASM library driver configuration            [  OK  ]
Scanning system for ASM disks                              [  OK  ]

Configuring Disks for ASM
Next you tell the ASM driver which disks you want it to use. Note that these are bare disks with nothing on them (not even a partition). It is possible to use disk partitions with ASM, but it isn't recommended.

You mark disks for use by ASMLib by running the following command as root: 

/etc/init.d/oracleasm createdisk DISK_NAME device_name

(Tip: Enter the DISK_NAME in UPPERCASE letters. There is a bug in the current release that prevents the disks from being visible to the ASM instance if lowercase is used.) 

Ex:
# /etc/init.d/oracleasm createdisk VOL1 /dev/sdb
Marking disk "/dev/sdb" as an ASM disk                     [  OK  ]
# /etc/init.d/oracleasm createdisk VOL2 /dev/sdc
Marking disk "/dev/sdc" as an ASM disk                     [  OK  ]
# /etc/init.d/oracleasm createdisk VOL3 /dev/sdd
Marking disk "/dev/sdd" as an ASM disk                     [  OK  ]
# /etc/init.d/oracleasm createdisk VOL4 /dev/sdf
Marking disk "/dev/sdf" as an ASM disk                     [  OK  ]
# /etc/init.d/oracleasm createdisk VOL5 /dev/sdg
Marking disk "/dev/sdg" as an ASM disk                     [  OK  ]
# /etc/init.d/oracleasm createdisk VOL6 /dev/sdh
Marking disk "/dev/sdh" as an ASM disk                     [  OK  ]

The following example shows how to list all the disks marked for use by ASMLib. 

# /etc/init.d/oracleasm listdisks
VOL1
VOL2
VOL3
VOL4
VOL5
VOL6

Now that ASMLib is installed and the disks are marked for use, you can create an ASM instance and build a database that uses ASM for disk storage. This is easiest to accomplish with the Data Base Configuration Assistant (DBCA).

Log in as oracle and start DBCA: 

$ dbca

  1. Welcome
    • Click on Next.
  2. Operations
    • Select Create a Database.
  3. Database Templates
    • Select General Purpose.
  4. Database Identification
    • Enter the Global Database Name.
  5. Management Options
    • Select Configure the Database with Enterprise Manager.
    • Select Use Database Control for Database Management.
  6. Database Credentials
    • Select Use Same Password for All Accounts.
    • Enter the password and confirm.
  7. Storage Options
    • Select Automatic Storage Management (ASM).
  8. Create ASM Instance
    • Enter a password for the ASM instance, and confirm.
  9. A pop-up window appears, advising that DBCA will now create and start the ASM instance.
    • Click on OK.
  10. A pop-up window displaying a gearbox appears while the ASM instance is being created.
  11. ASM Disk Groups
    • The window shows no available disk groups, because this is a new ASM instance and you haven't created any yet.
    • Click on Create New.
  12. Create Disk Group
    • Disk Group Name
      - Enter a name, such as DATA1, for the disk group.
    • Redundancy
      - High mirrors data twice.
      - Normal mirrors data once.
      - External does not mirror data within ASM. This is typically used if an external RAID array is providing redundancy.
    • Select Member Disks
      - You have to tell ASM where to look for your ASMLib disks manually, so click on Change Disk Discovery Path
      -       A pop-up window appears for entry of the Disk Discovery Path.  Change the Disk Discovery Path to 'ORCL:*' .
      - Click on OK to continue.
    • You are returned to the Select Member Disks window.  All your ASMLib disks should now appear in the window.
      Select the disks for the disk group by clicking on the box at the beginning of the line. Click on OK when finished.
  13. ASM Disk Groups
    • You are returned to the ASM Disk Groups window. This time, the disk group you created in the previous step appears.
    • Select this disk group by clicking on the box at the beginning of the line. (Use a single disk group in this case.)
    • Click on Next.
  14. Database File Locations
    • Select Use Oracle-Managed Files.
    • Make sure the Database Area is set to the disk group you created. It has a leading plus sign—+DATA1, for example.
  15. Recovery Configuration
    • Select Specify Flash Recovery Area.
      - Flash Recovery Area—Enter the ASM disk group to be used for Flash Recovery.
      - Flash Recovery Area Size—Accept the default, 2048.
    • Select Enable Archiving if you want to use archivelog mode. For an evaluation database, you can leave this unchecked.
  16. Database Content
    • Select Sample Schemas.
    • You are not using Custom Scripts, so click on Next.
  17. Initialization Parameters
    • Accept the defaults and click on Next.
  18. Database Storage
    • Accept the defaults and click on Next.
  19. Creation Options
    • Select Create Database (the default) and click on Finish.
  20. Confirmation
    • Click on OK when you've finished reviewing Database Details.
  21. DBCA displays a list of actions and a progress bar. Database creation can take from several minutes to several hours, depending on your hardware.
  22. When the database creation is complete, a window appears, displaying a summary. Note the Enterprise Manager URL, and click on Exit.
    23.

Conclusion

Now that your database is up and running, you can begin exploring the many new features offered in Oracle Database 10g. A great place to start is Oracle Enterprise Manager, which has been completely re-written with a crisp new Web-based interface. If you're unsure where to begin, the Oracle Database 10g Concepts Guide and the 2-Day DBA Guide will help familiarize you with your new database. OTN also has a number of guides designed to help you get the most out of 10g. One of my favorites is the series by Arup Nanda, "Oracle Database 10g: The Top 20 Features for DBAs."

Appendix

Using Oracle Enterprise Manager 10g Database Control

In a Web browser, connect to the URL provided during the installation.
http://IPADDRESS:5500/em (You can use the host name if your database server is in your DNS.)

User Name: SYS
Password: <The password you chose during installation>
Connect As: SYSDBA

Click on <Login>


Starting and Stopping Oracle Enterprise Manager Database Control:

$ emctl start dbconsole
$ emctl stop dbconsole

Accessing the Database Using iSQL*Plus
iSQL*Plus is a Web-based version of the venerable SQL*Plus interactive tool for accessing databases. To use iSQL*Plus, click on the iSQL*Plus link in the Related Links section of the OEM console or point your browser to the iSQL*Plus URL provided during installation.
Ex:
http://ds1.orademo.org:5560/isqlplus (You may have to use the IP address instead of the host name if your database server isn’t in your DNS.)

User Name: SYSTEM
Password: <The password you chose during installation>

Click on <Login>.

Enter SQL commands in the Workspace box, and click on Execute.

Starting and Stopping iSQL*Plus:

$ isqlplusctl start
$ isqlplusctl stop

List the Oracle Processes:

$ ps –fuoracle


Tips and Hints for Oracle10g on Linux

  • To reinstall Oracle10g after a failed installation attempt, you might want to execute the following commands.



    • Part V:Tuning Linux for Oracle
    On a 4 GB RAM machine, the size of the SGA (SGA utilizes shared memory) can be increased up to is 2.7 GB. This requires changes in Linux and Oracle. By default, the maximum size is 1.7 GB.
    On a 8 GB RAM machine, the size of the SGA can be increased up to 7 GB by using the shared memory filesystem "shmfs". A maximum size of 5.4 GB of SGA can be created using the "bigpages" feature for System V shared memory where the page size is 4 MB vs. the regular 4 KB.
    On a machine that supports Physical Address Extension (PAE), the SGA can theoretically have a size of 62 GB. The PAE mechanism allows addressing using 36 bits on IA-32 systems. But current hardware limitations and practical consideration limit the actual size of the SGA on such systems.

    The number of local concurrent users on a 4 GB server in non-MTS mode can range from 600 through 1200 without becoming unacceptable slow. For more information on the tpcc run that measured the number of concurrent users, see Linux Virtual Memory in Red Hat Advanced Server 2.1 and Oracle's Memory Usage Characteristics.

    Red Hat Linux Advanced Server has several features and enhancements that don't exist in other Red Hat versions. Among other things, Red Hat AS provides:
    - Asynchronous I/O
    - Process scheduler with CPU affinity, cache affinity, and per CPU runqueues and locks that provide better performance
    - "mapped base" (base address for shared libaries) can be changed dynamically allowing larger sizes for the SGA
    - Page frame of size 4 MB as opposed to 4 KB can be used for the SGA which improves performance for large SGAs
    - The kernel can also use the "high memory" pool (physical memory above 1 GB) for allocating page table entries (PTE) which allow a higher number of Oracle connections
    - Elimination of copy to bounce buffer improves I/O performance

    The recommended kernel for Red Hat Enterprise Linux 2.1 is 2.4.9-e.25 or higher. This kernel has several fixes that are relevant to Oracle including fixes for memory problems and kswapd problems.

    If the Linux server has <= 4 GB RAM, the kernel "kernel-smp" should be used for SMP machines, or the kernel "kernel" should be used for UP machines. If the Linux server has > 4 GB RAM, the enterprise kernel "kernel-enterprise" should be used for UP and SMP machines.

    To check if these kernels are installed, execute e.g. the following command: 
    rpm -q kernel-smp kernel-enterprise
     To check which kernel is currently running, execute the following command: 
    uname -a
    To install e.g. the enterprise kernel, download the "kernel-enterprise" RPM and execute the following command: 
    rpm -ivh kernel-enterprise-2.4.9-e.25.i686.rpm

    To make sure that the right kernel is booted, check the /etc/grub.conf file if you use GRUB, and change the "default" attribute if necessary. Here is an example: 
    default=1
    timeout=10
    splashimage=(hd0,1)/boot/grub/splash.xpm.gz
    title Red Hat Linux (2.4.9-e.25enterprise)
            root (hd0,1)
            kernel /boot/vmlinuz-2.4.9-e.25enterprise ro root=/dev/hda2 hdc=ide-scsi
            initrd /boot/initrd-2.4.9-e.25enterprise.img
    title Red Hat Linux Advanced Server (2.4.9-e.25smp)
            root (hd0,1)
            kernel /boot/vmlinuz-2.4.9-e.25smp ro root=/dev/hda2 hdc=ide-scsi
            initrd /boot/initrd-2.4.9-e.25smp.img
    title Red Hat Linux Advanced Server-up (2.4.9-e.25)
            root (hd0,1)
            kernel /boot/vmlinuz-2.4.9-e.25 ro root=/dev/hda2 hdc=ide-scsi
            initrd /boot/initrd-2.4.9-e.25.img
    In this example, the "default" attribute is set to "1" which means that the 2.4.9-e.25smp kernel will be booted. If the "default" attribute would be set to "0", then the 2.4.9-e.25enterprise kernel would be booted.

    After you installed the new kernel and/or made changes to the /etc/grub.conf file, reboot the server.

    Once you are sure you don't need the old kernel anymore, you can remove the old kernel by running: 
    su - root
    rpm -e <OldKernelVersion>
    When you remove the kernel, you don't need to make any changes to the /etc/grub.conf file.

    NOTE: Be very careful when removing a kernel! Making a mistake could render the server unbootable.


    Setting Asynchronous I/O

    Red Hat Advanced Server supports asynchronous I/O in the kernel. Asynchronous I/O permits Oracle to continue processing after issuing I/Os requests which leads to much higher I/O throughputs. This enhancement also allows Oracle to issue thousands of simultaneous I/O requests with a single system call. It also reduces context switch overhead.

    According to a Red Hat webcast I attended, only 2 Oracle dbwriter processes are needed when asynchronous I/O is being used.

    To enable Oracle to use asynchronous I/O, it is necessary to relink Oracle. Oracle ships Oracle9iR2 with asynchronous I/O support disabled. According to Oracle, this is necessary to accommodate other Linux distributions that do not support asynchronous I/O.

    Relinking Oracle to Enable Asynchronous I/O for Oracle9iR2 
    # shutdown Oracle
    SQL> shutdown

    su - oracle
    cd $ORACLE_HOME/rdbms/lib
    make -f ins_rdbms.mk async_on
    make -f ins_rdbms.mk ioracle

    # The last step creates a new "oracle" executable "$ORACLE_HOME/bin/oracle".
    # It backs up the old oracle executable to $ORACLE_HOME/bin/oracleO,
    # it sets the correct privileges for the new Oracle executable "oracle",
    # and moves the new executable "oracle" into the $ORACLE_HOME/bin directory.
    If asynchronous I/O needs to be disabled for any reason, run the following commands: 
    # shutdown Oracle
    SQL> shutdown

    su - oracle
    cd $ORACLE_HOME/rdbms/lib
    make -f ins_rdbms.mk async_off
    make -f ins_rdbms.mk ioracle

    Enabling Asynchronous I/O in init.ora for Raw Devices

    The disk_asynch_io init.ora parameter needs to be set to true: 
    disk_asynch_io=true
    Note that this init.ora parameter is already set to true by default: 
    SQL> select value, isdefault from v$parameter where name = 'disk_asynch_io';

    VALUE                          ISDEFAULT
    ------------------------------ ---------
    TRUE                           TRUE

    Enabling Asynchronous I/O in init.ora for Filesystem Files

    Make sure that all Oracle datafiles reside on filesystems that support asynchronous I/O (e.g. "ext2"). According to Oracle's white paper     Oracle9iR2 on Linux: Performance, Reliability and Manageability Enhancements on Red Hat Linux Advanced Server 2.1", Oracle9iR2 has been certified with the standard Linux filesystem "ext2" on RH AS 2.1. In addition, Oracle has also been certified for raw devices.

    The disk_asynch_io init.ora parameter needs to be set to true (same as for raw devices): 
    disk_asynch_io=true
    Note that this init.ora parameter is already set to true by default: 
    SQL> select value, isdefault from v$parameter where name = 'filesystemio_options';

    VALUE                          ISDEFAULT
    ------------------------------ ---------
    none                           TRUE

    SQL>

    The filesystemio_options init.ora parameter needs to be set to asynch: 
    filesystemio_options=asynch
    This init.ora parameter is platform-specific. By default, this parameter is set to none for Linux and thus needs to be changed. 
    SQL> select value, isdefault from v$parameter where name = 'filesystemio_options';

    VALUE                          ISDEFAULT
    ------------------------------ ---------
    none                           TRUE

    SQL>
    The filesystemio_options can have the following values with Oracle9iR2:
       asynch: This value enables asynchronous I/O on file system files.
       directio: This value enables direct I/O on file system files.
       setall: This value enables both asynchronous and direct I/O on file system files.
       none: This value disables both asynchronous and direct I/O on file system files.


    Increasing I/O Throughput at the Linux OS Level

    The /proc/sys/fs/aio-max-size parameter can be changed if asynchronous I/O is used for Oracle datafiles residing on filesystems (e.g. "ext2"). To my knowledge, this parameter does not have any effect to raw devices. According to the     Oracle9iR2 on Linux: Performance, Reliability and Manageability Enhancements on Red Hat Linux Advanced Server 2.1" document, Oracle9iR2 has been certified with the standard Linux filesystem "ext2" on RH AS 2.1.

    To get better I/O throughput for Decision Support Systems (DSS) workloads, the /proc/sys/fs/aio-max-size parameter should be increased to > 1 MB. A typical DSS system queries large amount of data and makes heavy use of full table scans. Parallel Query is particularly designed for DSS.

    For Online Transaction Processing (OLTP) workloads, the default size of 131072 would suffice. A typical OLTP system has high throughputs, are insert- and update-intensive, have concurrent access by many users, and have large, continuously growing data volume.

    To determine the number of bytes, run: 
    su - root
    # cat /proc/sys/fs/aio-max-size
    131072
    The maximum number of bytes can be changed for e.g. DSS systems in the proc file system without reboot: 
    echo "2147483648" > /proc/sys/fs/aio-max-size
    Alternatively, you can use sysctl(8) to change it: 
    sysctl -w fs.aio-max-size=2147483648
    To make the change permanent, add or change the following line in the file /etc/sysctl.conf. This file is used during the boot process. 
    echo "fs.aio-max-size=2147483648" >> /etc/sysctl.conf

    Increasing Space for larger SGA (2.7 GB) to Fit Into Memory

    If the size of SGA does not need to be increased from 1.7 GB to 2.7 GB, then the following steps can be skipped.

    By default, the maximum size for SGA is 1.7 GB on a 32-bit system without Physical Address Extension (PAE). You will also be able to allocate 1.7 GB SGA if you have less than 4 GB RAM. In this case you have to make sure you have enough swap space, however, this will have an impact to the performance of the database. I was even able to bring up a database with a SGA size of 2.64 GB on a test PC that had 256 MB RAM.

    Theoretically, the SGA can have a size of up to 62 GB on a system that supports Physical Address Extension (PAE). The PAE mechanism allows addressing using 36 bits on IA-32 systems. But current hardware limitations and practical consideration limit the actual size of the SGA on such a system. Since I do not have such a system, I will not cover the steps for creating SGAs larger than 2.7 GB via the     tmpfs filesystem.

    To increase the size of the SGA to 2.7 GB without using a shared memory filesystem (tmpfs), the following needs to be done:
      - The base address "mapped base" for Oracle's shared libraries has to be lowered at the Linux OS level.
      - Oracle needs to be relinked with a lower base address for SGA which uses shared memory segments.


    Address Mappings on Linux - Shared Memory and Shared Library Mapping on Linux

    Normally, the 4 GB linear address space (also known as virtual address space) for a 32-bit Linux system is split into 4 equal sized sections for different purposes: 
    0GB-1GB  User space   - Used for executable and brk/sbrk allocations (malloc uses brk for small chunks).
    1GB-2GB  User space   - Used for mmaps (shared memory), shared libraries and malloc uses mmap (malloc uses mmap for large chunks).
    2GB-3GB  User space   - Used for stack.
    3GB-4GB  Kernel Space - Used for the kernel itself.
    - The mmaps grow bottom up and the stack grows top down. The unused space used by the one can be used by the other.
    - The split between userspace and kernelspace can be changed by setting the kernel parameter PAGE_OFFSET and recompiling the kernel. By default, the PAGE_OFFSET macro yields the value 0xc0000000.
    - The split between brk(2) and mmap(2) can be changed by setting the kernel parameter TASK_UNMAPPED_BASE and recompiling the kernel. However, on Red Hat AS this parameter can be changed for individual processes dynamically without reboot or kernel recompilation.

    Usually, the portion of address space available for mapping shared libraries and shared memory segments consists of virtual addresses in the range of 0x40000000 (1 GB) - 0xc0000000 (3 GB). On Red Hat AS, 0x40000000 is the default base address for shared libraries and shared memory segments. The default base address for mapping shared memory segments can be changed and overwritten for programs and applications by non-root users. The default base address "mapped base" for loading shared libraries for programs and applications can be changed by the user root only.

    The default base address that Oracle uses for SGA (shared memory segment) is 0x50000000 and not 0x40000000. Oracle uses or keeps the space from 0x40000000-0x50000000 for loading Oracle shared libraries. As I mentioned before, 0x40000000 is the default base address on RH AS for loading shared libraries which can only be changed by the user root. Oracle increased the base address for SGA to prevent address range conflicts between the segments (shared memory segment and shared libraries).
    If the base address for shared memory segments would be 0x15000000 and if the base address for shared libraries would be 0x40000000, then Oracle cannot create the SGA larger than 0x2b000000 bytes or 688 MB, even though there is address space available above the shared libraries portion. (According to Oracle, Oracle binaries will no longer work if the base address for shared memory segments is lower than the base address shared libraries like in this example. Even though I didn't experience any problems, I would not recommend it).
    If the base address for shared memory segments is 0x50000000 and if the base address for shared libraries is 0x40000000, then Oracle can create a SGA that starts at 0x50000000 and ends almost at 0xc0000000; 0xc0000000 is the address where the kernel address space begins. This means that the SGA can have a size of almost 0x70000000 bytes or 1.792 GB - actually it's about 100 MB less due to stack space and other use of memory.

    Once again, Oracle increased the default base address for SGA to 0x50000000 so that all shared libraries can be loaded below 0x50000000, and the rest of the space up to almost 0xc0000000 can be used for shared memory.

    You can verify the address mappings of Oracle processes by viewing the proc file /proc/<pid>/maps where <pid> stands for the Oracle process ID. The default mapping of an Oracle process might look like this: 
    08048000-0ab11000 r-xp 00000000 08:09 273078     /ora/product/9.2.0/bin/oracle
    0ab11000-0ab99000 rw-p 02ac8000 08:09 273078     /ora/product/9.2.0/bin/oracle
    0ab99000-0ad39000 rwxp 00000000 00:00 0
    40000000-40016000 r-xp 00000000 08:01 16         /lib/ld-2.2.4.so
    40016000-40017000 rw-p 00015000 08:01 16         /lib/ld-2.2.4.so
    40017000-40018000 rw-p 00000000 00:00 0
    40018000-40019000 r-xp 00000000 08:09 17935      /ora/product/9.2.0/lib/libodmd9.so
    40019000-4001a000 rw-p 00000000 08:09 17935      /ora/product/9.2.0/lib/libodmd9.so
    4001a000-4001c000 r-xp 00000000 08:09 16066      /ora/product/9.2.0/lib/libskgxp9.so
    ...
    42606000-42607000 rw-p 00009000 08:01 50         /lib/libnss_files-2.2.4.so
    50000000-50400000 rw-s 00000000 00:04 163842     /SYSV00000000 (deleted)
    51000000-53000000 rw-s 00000000 00:04 196611     /SYSV00000000 (deleted)
    53000000-55000000 rw-s 00000000 00:04 229380     /SYSV00000000 (deleted)
    ...
    bfffb000-c0000000 rwxp ffffc000 00:00 0

    As this address mapping shows, shared libraries start at base address 0x40000000. The address mapping also shows that Oracle uses the base address 0x50000000 for SGA (in this example System V shared memory for SGA). Here is a summary of all the entries:

    The text (code) section is mapped at 0x08048000: 
      08048000-0ab11000 r-xp 00000000 08:09 273078     /ora/product/9.2.0/bin/oracle
    The data section is mapped at 0x0ab11000: 
      0ab11000-0ab99000 rw-p 02ac8000 08:09 273078     /ora/product/9.2.0/bin/oracle
    The uninitialized data segment .bss is allocated at 0x0ab99000: 
      0ab99000-0ad39000 rwxp 00000000 00:00 0
    The base address for shared libraries is 0x40000000: 
      40000000-40016000 r-xp 00000000 08:01 16         /lib/ld-2.2.4.so
    The base address for SGA (System V shared memory) is 0x50000000: 
      50000000-50400000 rw-s 00000000 00:04 163842     /SYSV00000000 (deleted)
    The stack is allocated at 0xbfffb000: 
      bfffb000-c0000000 rwxp ffffc000 00:00 0

    Now it should become clear what needs to be done to provide more space for SGA. To increase the space for SGA, two base addresses need to be changed. The base address "mapped base" for shared libraries needs to be lowered at the Linux OS level, and the base address for SGA (shared memory) needs to be lowered at the Oracle level (application level).

    Note: Once the base addresses have been changed at the Linux OS level and at the Oracle level, all Oracle commands need to be executed with a lower "mapped base"! This means that every new shell must run with a lowered "mapped base". Further down I will show you how you can automate this so that every Oracle user gets automatically a shell with a lowered "mapped base".


    Changing the Base Address "mapped base" for Shared Libraries at the Linux OS Level

    The default base address "mapped base" on RH 2.1AS is TASK_UNMAPPED_BASE = 0x40000000 (decimal 1073741824 or 1 GB). This is the address that splits the section between brk(2) and mmap(2), which defines available space for shared libraries (if it hasn't been changed and overwritten at the application level) and for shared memory (e.g. SGA).

    To change "mapped base" for a Linux process, the file /proc/<pid>/mapped_base needs to be changed where <pid> stands for the process ID. Note that this is not a system wide parameter! So in order to change "mapped base" for the Oracle database (i.e. Oracle processes), the parent shell that starts the database needs to be modified at the Linux OS level to allow it's child processes to inherit the change. The following procedure shows how this can be done.

    Execute the following command to identify the process ID "pid" of the shell process used by the Oracle user that will start the database: 
    echo $$
    As root in another shell, change "mapped base" to 0x10000000 (decimal 268435456 bytes or 256 MB) for the Oracle shell with the pid we identified above: 
    su - root
    echo 268435456 > /proc/<pid>/mapped_base
    This will tell the kernel to load shared libraries at the virtual address portion starting at 0x10000000. Now if Oracle is started with sqlplus in the shell used by the Oracle user for which we changed "mapped base", the Oracle processes will inherit the new base address.

    Once the     base address for shared memory has been changed at the Oracle level as well, more space will become available for the SGA. To accommodate the increased space for shared memory allocations by the Oracle processes, the maximum value of SHMMAX needs to be raised. This value defines the largest shared memory segment size allowed by the kernel. Since the SGA can be increased up to 2.7 GB with this method, the maximum size for SHMMAX can be rounded to 3000000000. This will allow Oracle to allocate one large shared memory segment for the SGA. This is also what Oracle recommends.

    The maximum size SHMMAX for a shared memory segment can be changed in the proc file system without reboot: 
    su - root
    echo "3000000000" > /proc/sys/kernel/shmmax
    Alternatively, you can use sysctl(8) to change it: 
    sysctl -w kernel.shmmax=3000000000
    To make the change permanent, add or change the following line in the file /etc/sysctl.conf. This file is used during the boot process. 
    kernel.shmmax=3000000000

    Changing the Base Address for Shared Memory at the Oracle Level

    The previous steps showed how to lower the base address "mapped base" for Oracle's shared libraries to 0x10000000 (256 MB). The following steps show how to lower the base address for shared memory (SGA) for Oracle to 0x15000000 (336 MB).

    The base address for SGA (shared memory) should not be lowered to 0x10000000 at the Oracle level. As I explained in the section "     Address Mappings on Linux - Shared Memory and Shared Library Mapping on Linux", to prevent address range conflicts between the segments (Oracle shared libraries and Oracle shared memory), the address at which the SGA should be attached is 0x15000000. It can be lowered to 0x12000000, but this would require thorough testing. So I would not recommend it.

    The following calculation shows how large the SGA can be created: 
       0xc0000000  (base address of the kernel space -> 3 GB)
     - 0x15000000  (base address of SGA -> 336 MB)
     -------------
       0xab000000  (decimal 2868903936 or 2.736 GB)
     - stack space
     - other memory allocations
     ------------
     ~ 2.65 to 2.70 GB

    To lower the base address at which the SGA (shared memory) should be attached, Oracle needs to be relinked. Changing the base address for SGA can be done on Linux with genksms, which is an Oracle utility: 
      # shutdown Oracle
      SQL> shutdown

      su - oracle
      cd $ORACLE_HOME/rdbms/lib

      # Make a backup of the ksms.s file if it exists
      [[ -f ksms.s ]] && cp ksms.s ksms.s_orig

          # Modify the attach address in the ksms.s file before relinking Oracle
      genksms -s 0x15000000 > ksms.s

    Rebuild the Oracle executable in the $ORACLE_HOME/rdbms/lib directory by entering the following commands: 
      # Create a new ksms object file
      make -f ins_rdbms.mk ksms.o

          # Create a new "oracle" executable ($ORACLE_HOME/bin/oracle):
      make -f ins_rdbms.mk ioracle

          # The last step will create a new Oracle kernel that loads the SGA at
      # the address specified by sgabeg in ksms.s:
      # .set   sgabeg,0X15000000
      # It also backs up the old oracle executable to $ORACLE_HOME/bin/oracleO,
      # it sets the correct privileges for the new Oracle executable "oracle", and
      # moves the new executable "oracle" into the $ORACLE_HOME/bin directory.

    Now when Oracle is started, the lowered base addresses for Oracle's shared library and shared memory (SGA) can be seen with the following commands: 
      # Get the pid of e.g. the Oracle checkpoint process
      su - oracle
      $ pgrep -f -x ora_dbw0_$ORACLE_SID -l
      13519 ora_dbw0_test
      # You can also use /sbin/pidof to get the process ID
      $ /sbin/pidof ora_dbw0_$ORACLE_SID
      13519
      $ DBW0_PID=`pgrep -f -x ora_dbw0_$ORACLE_SID`
      $ echo $DBW0_PID
      13519

      # Check the base addresses for shared libraries and shared memory for the
      # process ID 1049:

      $ grep '.so' /proc/$DBW0_PID/maps |head -1
      10000000-10016000 r-xp 00000000 03:02 750738     /lib/ld-2.2.4.so

      $ grep 'SYS' /proc/$DBW0_PID/maps |head -1
      15000000-24000000 rw-s 00000000 00:04 262150     /SYSV3ecee0b0 (deleted)
      $
    Now you can increase the init.ora parameters db_cache_size or db_block_buffer to create a larger database buffer cache. If the size of the SGA is larger than 2.65 GB, then I would test the database very thoroughly to make sure no other memory allocation problems arise.

    For fun I tried to test these settings on a little test PC with 256 MB RAM and 4 GB swap space. I wanted to see if I was able to bring up a database on such a little PC. I set db_block_buffer to 315000 and db_block_size to 8192 (2580480000 bytes), and I was able to bring up a database with 2.654 GB (2850033824 bytes) SGA on this PC: 
    Total System Global Area 2850033824 bytes
    Fixed Size                   450720 bytes
    Variable Size             268435456 bytes
    Database Buffers         2580480000 bytes
    Redo Buffers                 667648 bytes


    Giving Oracle Users the Privilege to Change the Base Address for Oracle's Shared Libraries Without Giving them root Access

    As shown above, only root can change the base address "mapped base" for shared libraries. Using sudo we can give Oracle users the privilege to change "mapped base" for their own shells without giving them full root access. Here is the procedure: 
    su - root

    # E.g. create a script called "/usr/local/bin/ChangeMappedBase"
    # which changes the "mapped base" for the parent process,
    # the shell used by the Oracle user where the "sudo" program
    # is executed (forked). Here is an example:

    #/bin/sh
    # Lowering "mapped base" to 0x10000000
    echo 268435456 > /proc/$PPID/mapped_base

    # Make sure that owernship and permissions are correct
    chown root.root /usr/local/bin/ChangeMappedBase
    chmod 755 /usr/local/bin/ChangeMappedBase

    # Allow the Oracle user to execute /usr/local/bin/ChangeMappedBase via sudo
    echo "oracle   ALL=/usr/local/bin/ChangeMappedBase" >> /etc/sudoers

    Now the Oracle user can run /usr/local/bin/ChangeMappedBase to change "mapped base" for it's own shell: 
    $ su - oracle
    $ cat /proc/$$/mapped_base; echo
    1073741824
    $ sudo /usr/local/bin/ChangeMappedBase
    Password:   # type in the password for the Oracle user account
    $ cat /proc/$$/mapped_base; echo
    268435456
    $
    When /usr/local/bin/ChangeMappedBase is executed the first time after an Oracle login, sudo will ask for a password. The password that needs to be entered is the password of the Oracle user account.


    Changing the Base Address for Oracle's Shared Libraries Automatically During an Oracle Login

    The procedure in the previous section asks for a password each time /usr/local/bin/ChangeMappedBase is executed the first time after an Oracle login. To have "mapped base" changed automatically during an Oracle login without a password, the following can be done:

    Edit the /etc/sudoers file with visudo: 
    su - root
    visudo
    Change the entry in /etc/sudoers from: 
    oracle   ALL=/usr/local/bin/ChangeMappedBase
    to read: 
    oracle   ALL=NOPASSWD: /usr/local/bin/ChangeMappedBase
    Make sure bash executes /usr/local/bin/ChangeMappedBase during the login process. You can use e.g. ~oracle/.bash_profile: 
    su - oracle
    echo "sudo /usr/local/bin/ChangeMappedBase" >> ~/.bash_profile
    The next time you login to Oracle, the base address for shared libraries will bet set automatically. 
    $ ssh oracle@localhost
    oracle@localhost's password:
    Last login: Sun Apr  6 13:59:22 2003 from localhost
    $ cat /proc/$$/mapped_base; echo
    268435456
    $

    Important Notes

    When the base address "mapped base" for Oracle's processes has changed, then every Linux shell that spawns Oracle processes (e.g. listener) must have the same "mapped base" as well. This means that even shells that are used to connect locally to the database need to have the same "mapped base". For example, if you run sqlplus to connect to the local database, then you will get the following error message if "mapped base" of this shell is not the same as for the Oracle processes: 
    SQL> connect scott/tiger
    ERROR:
    ORA-01034: ORACLE not available
    ORA-27102: out of memory
    Linux Error: 12: Cannot allocate memory
    Additional information: 1
    Additional information: 491524

    SQL>

    Using Large Memory Pages (Bigpages)

    This feature is very useful for large SGA sizes. In the following example I will show how to use and configure Linux bigpage memory area for System V shared memory segments. System V shared memory segments are allocated for SGA if "shmfs" is not used or configured for SGA.

    A separate Linux memory area can be allocated to use 4 MB memory pages rather than the normal 4 kB pages. Large memory pages "bigpages" are locked in memory and do not get swapped out. This means that a whole separate pigpage memory area can be allocated for the entire SGA not to get swapped out of memory. This means that it is very important that the bigpage memory area is only as large as needed for SGA because unused memory in the bigpage pool won't be available for other use than for shared memory allocations, even if the Linux system starts swapping. It is also important to be aware that if bigpages is set to a high value, then the available memory for user connection will be low.

    Sizing Bigpages

    Oracle says that the maximum value of Bigpages should be: 
    Maximum value of Bigpages = HighTotal / 1024 * 0.8 MB
    The bigpage memory area is only available for shared memory. So if bigpages is set to a high value, then the available memory for user connection will be low. If the memory consumption for the maximum number of user connections is known, then Oracle says that bigpages can be calculated as follows: 
    Maximum value of Bigpages = (HighTotal - Memory required by maximum user connections in KB) / 1024 * 0.8 MB
    According to Oracle's white paper Linux Virtual Memory in Red Hat Advanced Server 2.1 and Oracle's Memory Usage Characteristics, the assumption is that 20% of memory is reserved for kernel bookkeeping.

    The value for "HighTotal" can be obtained with the following command: 
    grep HighTotal /proc/meminfo
    Note that highmem is all memory above (approx) 860MB of physical RAM. This means that "HighTotal" is the the total amount of memory in the high memory region. It should now be clear that large memory pages should only be configured if enough physical RAM is available. For instance, if the server has only 512 MB RAM, then "HighTotal" will be 0 kB. And on my 1 GB RAM desktop PC, "HighTotal" shows 130992 kB.

    Here are a few examples for bigpage sizes taken from Tips and Techniques: Install and Configure Oracle9i on Red Hat Linux Advanced Server: 
    2 GB SGA    2100 MB bigpages
    4 GB SGA    4100 MB bigpages
    The bigpages feature allows a maximum size of 5.4 GB SGA on a machine with 8 GB RAM.

    Configuring Bigpages

    The kernel needs to be told to use the bigpages pool for shared memory allocations. The bigpages feature can be enabled for System V shared memory in the proc file system without reboot with the following command: 
    su - root
    echo "1" > /proc/sys/kernel/shm-use-bigpages
    Alternatively, you can use sysctl(8) to change it: 
    sysctl -w kernel.shm-use-bigpages=1
    To make the change permanent, add the following line to the file /etc/sysctl.conf. This file is used during the boot process. 
    echo "kernel.shm-use-bigpages=1" >> /etc/sysctl.conf
    Setting kernel.shm-use-bigpages=2 will enable bigpages for "    shmfs" which I'm not covering in this article. Setting kernel.shm-use-bigpages=0 will disable the bigpages feature.

    The kernel needs to be told how large the bigpage pool should be. If you use GRUB, add the "bigpages" parameter in the etc/grub.conf file and set the maximum value of bigpages as follows. In this example I will set bigpages to 2100 MB for the SMP kernel 2.4.9-e.25 that is started on my database server: 
    default=1
    timeout=10
    splashimage=(hd0,1)/boot/grub/splash.xpm.gz
    title Red Hat Linux (2.4.9-e.25enterprise)
            root (hd0,1)
            kernel /boot/vmlinuz-2.4.9-e.25enterprise ro root=/dev/hda2 hdc=ide-scsi
            initrd /boot/initrd-2.4.9-e.25enterprise.img
    title Red Hat Linux Advanced Server (2.4.9-e.25smp)
            root (hd0,1)
            kernel /boot/vmlinuz-2.4.9-e.25smp ro root=/dev/hda2 hdc=ide-scsi bigpages=2100MB
            initrd /boot/initrd-2.4.9-e.25smp.img
    title Red Hat Linux Advanced Server-up (2.4.9-e.25)
            root (hd0,1)
            kernel /boot/vmlinuz-2.4.9-e.25 ro root=/dev/hda2 hdc=ide-scsi
            initrd /boot/initrd-2.4.9-e.25.img

    After this change the system needs to be rebooted: 
    su - root
    shutdown -r now

    After a system reboot, the "MemFree" value (free system memory) in the /proc/meminfo is subtracted by 2100 MB in this example. The 2100 MB show now up in the "BigPagesFree" which means that 2100 MB are now in a separate allocation area: 
    grep MemTotal /proc/meminfo
    grep BigPagesFree /proc/meminfo
    Note that if you configure "bigpages" in the etc/grub.conf file and reboot the system, "BigPagesFree" in /proc/meminfo will be 0 KB if "HighTotal" in /proc/meminfo is 0 KB and if /proc/sys/kernel/shm-use-bigpages is set to "1".

    Making Other Performance Related Changes

    Disabling Unneeded Background Processes

    Disable or remove slocate from your system. The nightly slocate cron job can become a real performance killer for your database!

    Every night slocate updates a database for files on your system which match a given pattern. It helps you to find files on your system very quickly. However, when the cron job is run at night, it will flush the buffers, it can fragment your memory, and it could cause your system to do heavy paging.

    The easiest way is to disable updatedb in /etc/cron.daily/slocate.cron or to remove slocate from your system completely: 
    su - root
    rpm -e slocate

    X should not run unless you need to. You can stop X by switching to runlevel 3 with the following command: 
    init 3
    To switch back to runlevel 5 that X comes up again, run: 
    init 5
    To set the default runlevel permanently to 3 so that X doesn't come up with the next reboot, change the following line in /etc/inittab: 
     id:5:initdefault:
    so that it reads: 
     id:3:initdefault:

    You can check for other unneeded background processes by running the command: 
    /sbin/chkconfig --list
    To temporarely disable e.g. ypbind, run: 
    su - root
    service ypbind stop
    To permanently disable ypbind, run: 
    chkconfig ypbind off