Installing Oracle 9i on Red Hat Enterprise Linux Advanced Server 4

Installing Oracle 9i on Red Hat Enterprise Linux Advanced Server 4, 3, 2.1, and on Red Hat 9, 8.0, 7.3, 7.2, 7.1 (x86) Red Hat Enterprise Linux Advanced Server 3 (RHEL AS 3) In order to install an Oracle9iR2 database on RH AS 3, the "Oracle9iR2 Patch Set 3 9.2.0.4.0" patchset and some other patches must be applied. Some errors can only be fixed by applying the 9.2.0.4 patchset. For more information, see Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 3. Red Hat 9: Red Hat 9 includes the Native POSIX Thread Library (NPTL) which is an improved implementation of POSIX threads for Linux. But using NPTL will cause several problems for Oracle applications. Note that Oracle9i has not been certified on Red Hat 9! So to fix this problem, you can set the environment variable LD_ASSUME_KERNEL to 2.4.1, which means that the old "Linuxthreads with floating stacks" implementation will be used. Otherwise the Oracle installer runInstaller will hang, the Database Configuration Assistant dbca won't start etc.; see Oracle Installation Errors for more information. To see where this environment variable can be set, see Set Oracle Environments. For more information on LD_ASSUME_KERNEL, see Red Hat Linux 9 Release Notes. NOTE: Before you install Oracle9iR2, make sure that you first read the information about the error message "Error in invoking target install of make file /u01/app/oracle/product/9.2.0/network/lib/ins_oemagent.mk" in the Oracle Installation Errors section! Red Hat 8.0: The only problem I experienced with Oracle 9iR2 (9.2.0) on Red Hat 8.0 was: "Error in invoking target install of makefile /u01/app/oracle/product/9.2.0/ctx/lib/ins_ctx.mk" But this does not necessarily mean that you won't see other problems described here. See Oracle Installation Errors for more information. This article covers the following subjects and steps: * Documentations * Downloading and Installing Red Hat Linux 7.1, 7.2, 7.3, 8.0, 9 * Unpacking Downloaded Oracle9i Installation Files and Burning Oracle9i CDs * Setting Swap Space * Setting Shared Memory * Checking /tmp Space * Sizing Oracle Disk Space * The "binutils" Issue * Checking Packages (RPMs) * JDK * Creating Oracle User Accounts * Creating Oracle Directories * Setting Oracle Environments * Starting runInstaller * Running Oracle Installation on RH 7.1, 7.2, 7.3, 8.0, 9, and on RH AS 2.1 * Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 3 Installing Oracle9iR2 on RH AS 3 Patching Oracle9iR2 on RH AS 3 Patching Oracle Intelligent Agent on RH AS 3 * Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 4 Installing Oracle9iR2 on RH AS 4 Patching Oracle9iR2 on RH AS 4 * Startup and Shutdown of the Oracle 9i Database * Oracle Installation Problems, Tips and Hints * Oracle Installation Errors Documentations Oracle9i Database Documentation for Linux Tuning and Optimizing Red Hat Linux Advanced Server for Oracle9i Database Oracle9iR2 on Linux: Performance, Reliability and Manageability Enhancements on Red Hat Linux Advanced Server 2.1 An Overview of Red Hat Advanced Server V2.1 Reliability, Availability, Scalability, and Manageability (RASM) Features Downloading and Installing Red Hat Linux 7.1, 7.2, 7.3, 8.0, 9 To download Red Hat Linux 7.x, 8.0, 9, check the links at http://www.puschitz.com/LinuxDownload.shtml. You can find the installation guides for installing Red Hat Linux under Red Hat Linux Manuals. NOTE: You cannot download Red Hat Linux Advanced Server 2.1, you can only download the source code. If you want to get the binary CDs, you will have to buy it at http://www.redhat.com/software/linux/advanced/. Installing Software Packages (RPMs) You don't have to install all RPMs when you want to run an Oracle9i database on Red Hat Linux. For instance, if you install Red Hat Advanced Server, you are fine when you select the Installation Type "Advanced Server" and when you don't select the Package Group "Software Development". There are only a few other RPMs that are required for installing Oracle9i. These other RPMs are covered in this article. Or when you install Oracle9i on Red Hat Linux 7.x, 8.0, or 9, you are fine when you select the installation type "Server". Unpacking Downloaded Oracle9i Installation Files and Burning Oracle9i CDs Download Oracle9i for Linux from the following web site: http://otn.oracle.com/software/products/oracle9i/htdocs/linuxsoft.html Uncompress and unpack downloaded files: For Oracle9i (9.2.0): One step procedure (uses less disk space and is faster): zcat lnx_920_disk1.cpio.gz | cpio -idmv zcat lnx_920_disk2.cpio.gz | cpio -idmv zcat lnx_920_disk3.cpio.gz | cpio -idmv Two step procedure: # Uncompress gunzip lnx_920_disk1.cpio.gz lnx_920_disk2.cpio.gz lnx_920_disk3.cpio.gz Linux9i_Disk3.cpio.gz # Unpack the cpio -idmv < cpio -idmv < cpio -idmv < downloaded files: lnx_920_disk1.cpio lnx_920_disk2.cpio lnx_920_disk3.cpio For Oracle9i (9.0.1): One step procedure (uses less disk space and is faster): zcat Linux9i_Disk1.cpio.gz | cpio -idmv zcat Linux9i_Disk2.cpio.gz | cpio -idmv zcat Linux9i_Disk3.cpio.gz | cpio -idmv Two step procedure: # Uncompress gunzip Linux9i_Disk1.cpio.gz Linux9i_Disk2.cpio.gz Linux9i_Disk3.cpio.gz # Unpack the cpio -idmv < cpio -idmv < cpio -idmv < downloaded files: Linux9i_Disk1.cpio Linux9i_Disk2.cpio Linux9i_Disk3.cpio Now you should have 3 directories containing installation files: Disk1 Disk2 Disk3 I executed the following commands when I burned the 3 CDs: mkisofs -r Disk1 | cdrecord -v --eject dev=0,0,0 speed=15 mkisofs -r Disk2 | cdrecord -v --eject dev=0,0,0 speed=15 mkisofs -r Disk3 | cdrecord -v --eject dev=0,0,0 speed=15 (You can get the dev numbers when you execute cdrecord -scanbus). Setting Swap Space In order to perform a typical Oracle 9i installation and to create a simple prototype database, Oracle says that you need a minimum of 512MB of RAM for the Oracle9i (9.0.1) Server, and the amount of disk space (swap space) should be equal to twice the amount of RAM or at least 400 MB, whichever is greater. I tried to test the limits on an older PC with 256 MB of RAM and with 600 MB of swap space. I was able to install Oracle 9i (9.0.1 & 9.2.0) and Oracle's default database without any problems. But when I used less swap space on this PC (256MB RAM), I was runnig out of memory. So I definitely recommend to use more RAM and/or more swap space as specified in the Oracle installation guide. NOTE: If you do not have enough swap space or RAM during the Oracle installation, in particular during the database creation, your Oracle server (Linux) will temporarily become unresponsive to any events for several minutes. For more information on correctly sizing the swap space for your database, see Sizing Swap Space. To check the memory, run: grep MemTotal /proc/meminfo To check the swap space, run: cat /proc/swaps You can also add temporary swap space 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 Setting Shared Memory For Oracle 9i (9.2.0) installation I had to increase the maximum shared memory size on my Linux server for all Red Hat versions. The Oracle Database Configuration Assistant displayed the following error message on my server: ORA-27123: unable to attach to shared memory segment. I temporarely increased the shmmax setting for the kernel by executing the following command: $ su - root # cat /proc/sys/kernel/shmmax 33554432 # echo `expr 1024 \* 1024 \* 1024` > /proc/sys/kernel/shmmax # cat /proc/sys/kernel/shmmax 1073741824 It is recommended to increase the shmmax setting permanently for Oracle. For more information, see Setting Shared Memory. For more information on optimizing shared memory settings for Oracle databases on Linux, see Setting Shared Memory. These parameters apply to all Red Hat Linux versions. But note that except for the shmmax parameter, these parameter do not need to be changed for installing Oracle on Linux. But you might want to adjust all shared memory settings later to optimize the server for Oracle. Checking /tmp Space The Oracle Universal Installer requires up to 400 MB of free space in the /tmp directory. To check the space in /tmp, run: $ df /tmp If you do not have enough space in the /tmp directory, you can temporarily create a tmp directory in another filesystem. Here is how you can do this: su - root mkdir //tmp chown root.root //tmp chmod 1777 //tmp export TEMP=/ export TMPDIR=/ like the linker "ld" # used by Oracle # used by Linux programs When you are done with your Oracle installation, shutdown Oracle and remove the temporary directory: su - root rmdir //tmp unset TEMP unset TMPDIR Sizing Oracle Disk Space You will need about 2.5 GB for the database software. If you perform a typical database installation and not a customized database installation, then you will need about 3.5 GB of disk space. The "binutils" Issue Skip this step for Oracle9iR2. I did not experience this problem with Oracle 9i (9.2.0), but only with Oracle 9i (9.0.1). The binutils package that comes with Red Hat 7.1, 7.2, 7.3, and with RedHat 2.1 Advanced Server doesn't work with Oracle 9i (9.0.1) Universal Installer. Here are the options you have for 9.0.1:  I recommend the following approach: Wait for the following Oracle installation error: "Error invoking target install of makefile /u01/app/oracle/product/9.0.1/plsql/lib/ins_plsql.mk" And fix this problem as described in Oracle Installation Errors. I recommend this approach since it obviates the need to change binutils.  I do not recommend the following approach: Download the following binutil RPM version and downgrade binutil on the Oracle server: ftp://ftp.redhat.com/pub/redhat/linux/7.0/en/os/i386/RedHat/RPMS/binutils2.10.0.18-1.i386.rpm su - root rpm -Uvh --force --nodeps binutils-2.10.0.18-1.i386.rpm When you are done with the Oracle installation, you upgrade your binutil RPM back to the version you had before you downgraded. E.g. on the Red Hat 7.2 server I did: rpm -Uvh --force --nodeps binutils-2.11.90.0.8-9.i386.rpm  Here is Oracle's official solution for Oracle 9iR1 or 9iR1 iAS on RedHat 2.1 Advanced Server which I don't like: http://otn.oracle.com/software/products/oracle9i/files/binutils_readme.html Checking Packages (RPMs) You will need some RPM development packages for the Oracle installer to build the Oracle modules, otherwise you will get error messages similar to this one: Error in invoking target ntcontab.o of makefile /u01/app/oracle/product/9.2.0/network/lib/ins_net_client.mk NOTE: Always ensure to use the latest RPM versions! Packages (RPMs) for RH 7.1, 7.2, and RH AS 2.1: To see if these development packages are installed on your server, run the following command: rpm -q gcc cpp compat-libstdc++ glibc-devel kernel-headers binutils For instance, most of these packages will be missing when you installed RedHat 2.1 Advanced Server and if you did not select the "Software Development" package. For the RedHat 2.1 Advanced Server I executed the following commands to install the missing RPMs from the two CDs: su - root rpm -ivh cpp-2.96-108.1.i386.rpm \ glibc-devel-2.2.4-26.i386.rpm \ kernel-headers-2.4.9-e.3.i386.rpm \ gcc-2.96-108.1.i386.rpm \ binutils-2.11.90.0.8-12.i386.rpm Packages (RPMs) for RH 7.3, 8.0, and 9: To see if these development packages are installed on your server, run the following command: rpm -q gcc cpp compat-libstdc++ glibc-devel glibc-kernheaders binutils For instance, when I installed Red Hat 9.0 and when I used the default packages for the Installation Type "Server", I had to install the following RPMs afterwards: su - root rpm -ivh binutils-2.13.90.0.18-9.i386.rpm \ cpp-3.2.2-5.i386.rpm \ gcc-3.2.2-5.i386.rpm \ glibc-devel-2.3.2-5.i386.rpm \ glibc-kernheaders-2.4-8.10.i386.rpm NOTE: Before you install Oracle9iR2 on Red Hat 9, make sure that you also read the information about the error message "Error in invoking target install of make file /u01/app/oracle/product/9.2.0/network/lib/ins_oemagent.mk" in the Oracle Installation Errors section! Packages (RPMs) for Red Hat Enterprise Linux Advanced Server 3 (RHEL AS 3): Ensure the following required packages are installed on your server by running the following command: rpm -q make \ binutils \ gcc \ cpp \ glibc-devel \ glibc-headers \ glibc-kernheaders \ compat-db \ compat-gcc \ compat-gcc-c++ \ compat-libstdc++ \ compat-libstdc++-devel \ gnome-libs \ openmotif21 \ setarch Packages (RPMs) for Red Hat Enterprise Linux Advanced Server 4 (RHEL AS 4): See also Oracle9i Release Notes Release 2 (9.2.0.4.0) for Linux x86 for the list of required RPMs. Ensure the following required packages are installed on your server by running the following command: rpm -q make compat-db compat-gcc-32 compat-gcc-32-c++ compat-oracle-rhel4 compat-libcwait compat-libgcc-296 compat-libstdc++-296 compat-libstdc++-33 gcc gcc-c++ gnome-libs gnome-libs-devel libaio-devel libaio make openmotif21 xorg-x11-deprecated-libs-devel xorg-x11-deprecated-libs \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ Many of these packages depend on other packages. For example, compat-gcc-32 requires binutils, gcc etc. Since I like to install a system with as few RPMs as possible I had to install the following RPMs to satisfy dependencies: rpm -Uvh compat-db-4.1.25-9.i386.rpm compat-gcc-32-3.2.3-47.3.i386.rpm glibc-devel-2.3.4-2.i386.rpm glibc-headers-2.3.4-2.i386.rpm glibc-kernheaders-2.4-9.1.87.i386.rpm cpp-3.4.3-9.EL4.i386.rpm compat-gcc-32-c++-3.2.3-47.3.i386.rpm compat-libstdc++-33-3.2.3-47.3.i386.rpm gcc-3.4.3-9.EL4.i386.rpm cpp-3.4.3-9.EL4.i386.rpm gcc-c++-3.4.3-9.EL4.i386.rpm \ \ \ \ \ \ \ \ \ \ \ libstdc++-devel-3.4.3-9.EL4.i386.rpm openmotif21-2.1.30-11.RHEL4.2.i386.rpm xorg-x11-deprecated-libs-6.8.1-23.EL.i386.rpm compat-libgcc-296-2.96-132.7.2.i386.rpm compat-libstdc++-296-2.96-132.7.2.i386.rpm libaio-0.3.102-1.i386.rpm libaio-devel-0.3.102-1.i386.rpm \ \ \ \ \ \ For xorg-x11-deprecated-libs-devel and xorg-x11-devel I had to install the following RPMs. Note that these two packages are required for the Oracle patch 4198954 below. rpm -Uvh xorg-x11-deprecated-libs-devel-6.8.1-23.EL.i386.rpm \ xorg-x11-devel-6.8.1-23.EL.i386.rpm \ fontconfig-devel-2.2.3-7.i386.rpm \ pkgconfig-0.15.0-3.i386.rpm \ freetype-devel-2.1.9-1.i386.rpm \ zlib-devel-1.2.1.2-1.i386.rpm And for gnome-libs and gnome-libs-devel I had to install the following RPMs: rpm -Uvh gnome-libs-1.4.1.2.90-44.1.i386.rpm gnome-libs-devel-1.4.1.2.90-44.1.i386.rpm ORBit-0.5.17-14.i386.rpm ORBit-devel-0.5.17-14.i386.rpm alsa-lib-1.0.6-4.i386.rpm audiofile-0.2.6-1.i386.rpm esound-0.2.35-2.i386.rpm esound-devel-0.2.35-2.i386.rpm gtk+-1.2.10-33.i386.rpm gtk+-devel-1.2.10-33.i386.rpm imlib-1.9.13-23.i386.rpm imlib-devel-1.9.13-23.i386.rpm libpng10-1.0.16-1.i386.rpm alsa-lib-devel-1.0.6-4.i386.rpm audiofile-devel-0.2.6-1.i386.rpm gdk-pixbuf-0.22.0-15.1.i386.rpm glib-devel-1.2.10-15.i386.rpm indent-2.2.9-6.i386.rpm libjpeg-devel-6b-33.i386.rpm libtiff-devel-3.6.1-7.i386.rpm libungif-4.1.3-1.i386.rpm libungif-devel-4.1.3-1.i386.rpm \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ HINT: If you are using RHN, you could simply run: up2date gnome-libs gnome-libs-devel You can use the up2date command for any packages. It takes care of dependencies by installing all required packages automatically. To install the compat-oracle-rhel4 and compat-libcwait packages you have to download the patch 4198954 from http://metalink.oracle.com. Make sure to select the Linux x86 platform. To unzip the downloaded p4198954_21_LINUX.zip file, run: $ unzip p4198954_21_LINUX.zip Archive: p4198954_21_LINUX.zip creating: 4198954/ inflating: 4198954/compat-oracle-rhel4-1.0-5.i386.rpm inflating: 4198954/compat-libcwait-2.0-2.i386.rpm inflating: 4198954/README.txt # Note that the compat-oracle-rhel4 and compat-libcwait packages require the xorgx11-deprecated-libs and xorg-x11-deprecated-libs-devel packages, see above. To install the two RPMs from the 4198954 patch, run: # rpm -Uvh 4198954/compat-oracle-rhel4-1.0-5.i386.rpm \ 4198954/compat-libcwait-2.0-2.i386.rpm JDK Skip this step for Oracle9iR2. I successfully installed Oracle9iR2 without installing JDK on the system. Oracle comes now with its own Java. This means that you don't have to execute the following steps which were required for older Oracle versions: Download JDK 1.3.1 or Blackdown 1.1.8_v3: (I usually used Blackdown) http://www.blackdown.org http://java.sun.com According to the JDK documentation, install JDK under /usr/local. Then create a symbolic link to the JDK under /usr/local/java: su - root bzip2 -dc jdk118_v3-glibc-2.1.3.tar.bz2 | tar xf - -C ln -s /usr/local/jdk118_v3 /usr/local/java /usr/local Creating Oracle User Accounts su - root groupadd dba # group of users to be granted with SYSDBA system privilege groupadd oinstall # group owner of Oracle files useradd -c "Oracle software owner" -g oinstall -G dba oracle passwd oracle For more information on the "oinstall" group account, see When to use "OINSTALL" group during install of oracle. Creating Oracle Directories In this example, make sure that the /u01 filesystem is large enough, see Oracle Disk Space for more information. If /u01 is not on a separate filesystem, then make sure the root filesystem "/" has enough space. su - root mkdir -p /u01/app/oracle/product/9.2.0 chown -R oracle.oinstall /u01 mkdir /var/opt/oracle chown oracle.dba /var/opt/oracle chmod 755 /var/opt/oracle Setting Oracle Environments Set the following Oracle environment variables before you start runInstaller. As the oracle user execute the following commands: # Set the LD_ASSUME_KERNEL environment variable only for Red Hat 9, # RHEL AS 3, and RHEL AS 4 !! # Use the "Linuxthreads with floating stacks" implementation instead of NPTL: export LD_ASSUME_KERNEL=2.4.1 # for RH 9 and RHEL AS 3 export LD_ASSUME_KERNEL=2.4.19 # for RHEL AS 4 # Oracle Environment export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/9.2.0 export ORACLE_SID=test export ORACLE_TERM=xterm # export TNS_ADMIN= Set if sqlnet.ora, tnsnames.ora, etc. are not in $ORACLE_HOME/network/admin export NLS_LANG=AMERICAN; export ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export LD_LIBRARY_PATH # Set shell search paths export PATH=$PATH:$ORACLE_HOME/bin I successfully installed Oracle9iR2 without setting the following CLASSPATH environment variable: # CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib # CLASSPATH=$CLASSPATH:$ORACLE_HOME/network/jlib # export CLASSPATH You can put these environment settings at the end of the ~oracle/.bash_profile file if you use bash. By this way you don't have to set the environment variables again when you login as "oracle", or when you switch to the user "oracle" by executing "su oracle". Starting runInstaller Before you continue, make sure you have set the Oracle environment variables, see above. Oracle no longer supports a character mode installer. Therefore, in order to execute runInstaller directly from a console of a machine you are logged into (in this example the node name where Oracle is running is called "oracleserver"), you need to set the DISPLAY environment variable. Before you do that, make sure that you also allow runInstaller on "oracleserver" to display X information on your Linux desktop machine (in this example, the PC name where you are running X Windows like KDE or GNOME is called "yourdesktop"), because programs running on remote machines cannot display information to your screen unless you give them the authority to do so. Note that the X display relink mechanism does not work for NT desktop machines unless you use Exceed. Before you run runInstaller, execute e.g. 'xterm' to see if your X setup is really working! If you install Oracle on your desktop PC and not on a remote node, then you can skip step 1 and 3. Step 1: Allow "oracleserver" to display X information to your desktop PC "yourdesktop": yourdesktop:user$ xhost +oracleserver Step 2: Open a new window and login to the Oracle server "oracleserver" as root. This window will be used for mounting and unmounting the Oracle CDs. oracleserver:$ su - root oracleserver:root# mount /mnt/cdrom Step 3: From the console of your Oracle server "oracleserver" where you will run runInstaller, execute the following commands: oracleserver:$ su - oracle oracleserver:oracle$ export DISPLAY=yourdesktop:0.0 Step 4: Now execute runInstaller as "oracle". Do not cd to /mnt/cdrom oracleserver:oracle$ /mnt/cdrom/runInstaller !! NOTE 1: If you use for example Red Hat Fedora Core 3 as your desktop and you want to install the database on another machine, then you need to set the DisallowTCP entry in /etc/X11/gdm/gdm.conf for the GNOME Display Manager to read: DisallowTCP=false After that you need to restart your X server. I usually do this with the init command: su - root init 3 init 5 NOTE 2: Don't run runInstaller for Red Hat Enterprise Linux Advanced Server 3 (RHEL AS 3) yet! See Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 3 for more information. Running Oracle Installation on RH 7.1, 7.2, 7.3, 8.0, 9, and on RH AS 2.1 Keep in mind that you may get one or more errors here during the Oracle installation! See Oracle Installation Errors for more information. This is how I answered the questions for the runInstaller: - What would you like as the base directory (Inventory Location): /u01/app/oracle/oraInventory - UNIX Group Name (permission for updating Oracle software): oinstall You could also use "dba" which I do not recommend for security reasons. For more information on the "oinstall" group account, see When to use "OINSTALL" group during install of oracle. - Full path name for Oracle Home: /u01/app/oracle/product/9.2.0 etc. Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 3 In order to install an Oracle9iR2 database on RH AS 3, the "Oracle9iR2 Patch Set 3 9.2.0.4.0" patchset and some other patches must be applied. Some errors can only be fixed by applying the 9.2.0.4 patchset. Installing Oracle9iR2 on RH AS 3 Install the following RPMs (see Oracle Note:252217.1 for more information): su - root rpm -ivh \ compat-db-4.0.14-5.i386.rpm \ compat-gcc-7.3-2.96.122.i386.rpm \ compat-gcc-c++-7.3-2.96.122.i386.rpm \ compat-libstdc++-7.3-2.96.122.i386.rpm \ compat-libstdc++-devel-7.3-2.96.122.i386.rpm \ openmotif21-2.1.30-8.i386.rpm \ setarch-1.3-1.i386.rpm \ tcl-8.3.5-92.i386.rpm Relink gcc so that the older gcc will be used during the Oracle installation (see Oracle Note:252217.1 for more information): su - root mv /usr/bin/gcc /usr/bin/gcc323 ln -s /usr/bin/gcc296 /usr/bin/gcc mv /usr/bin/g++ /usr/bin/g++323 c++ was not installed # if g++ doesn't exist, then gcc- ln -s /usr/bin/g++296 /usr/bin/g++ When you execute runInstaller from the Oracle 9iR2 (9.2.0) CD, you will get the following error message: Error occurred during initialization of VM Unable to load native library: /tmp/OraInstall2003-10-25_03-1457PM/jre/lib/i386/libjava.so: symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference To resolve the __libc_wait symbol issue, download the patch p3006854_9204_LINUX.zip from http://metalink.oracle.com. See bug 3006854 for more information. To apply the patch, run su - root # unzip p3006854_9204_LINUX.zip Archive: p3006854_9204_LINUX.zip creating: 3006854/ inflating: 3006854/rhel3_pre_install.sh inflating: 3006854/README.txt # cd 3006854 # sh rhel3_pre_install.sh Applying patch... Patch successfully applied # NOTE: If you get the following error when you run rhel3_pre_install.sh: rhel3_pre_install.sh: line 36: gcc: command not found Then you forgot to install or link gcc, see above. This means you can't start any binaries any more: # ls ls: error while loading shared libraries: /etc/libcwait.so: cannot open shared object file: No such file or directory # rm /etc/ld.so.preload rm: error while loading shared libraries: /etc/libcwait.so: cannot open shared object file: No such file or directory # To fix that, run the echo command which is a built-in shell command: # echo "" > /etc/ld.so.preload rm /etc/ld.so.preload And start over again. Now runInstaller can be started from the CD: su - oracle $ echo $LD_ASSUME_KERNEL set! 2.4.1 $ /mnt/cdrom/runInstaller - Welcome Screen: - Inventory Location: # it is important that this variable is Click Next Click Next - Unix Group Name: Use "oinstall" and click Next When asked to run /tmp/orainstRoot.sh, run it before you click Continue - File Locations: Use default values - Available Products: Select "Oracle9i Database 9.2.0.1.0" - Installation Types: Select Custom since we only want to install the software for now - Available Products: Click Next or add some more components. - Components Locations: Accept default values and click Next - Privileged Operating System Groups: I used the default values: OSDBA Group = dba, OSOPER Group = dba - Oracle Managent Server Repository: I used the default choice - Create database: Select NO since we first have to patch Oracle before a database can be created! - Summary: Start the Install - Configuration tools: Tools won't come up. Simply ignore it. - At the end of the installation, exit runInstaller. You may get the following errors: Error in invoking target install of makefile /u01/app/oracle/product/9.2.0/network/lib/ins_oemagent.mk. The /u01/app/oracle/product/9.2.0/install/make.log file reads: /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x a4e): In function `Nls_FormatCmd': : undefined reference to `__ctype_b' /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x 159d): In function `Nls_ScanCmd': : undefined reference to `__ctype_b' /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x 1603): more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status make: *** [dbsnmp] Error 1 Click ignore. This will be fixed by applying the patch 3119415 after the 9.2.0.4 patchset has been applied. You won't be able to apply the patch 3119415 at this time since the file /u01/app/oracle/oraInventory/ContentsXML/comps.xml doesn't exist yet. Error in invoking target install of makefile /u01/app/oracle/product/9.2.0/ctx/lib/ins_ctx.mk. The /u01/app/oracle/product/9.2.0/install/make.log file reads: /usr/bin/ld: ctxhx: hidden symbol `stat' in /usr/lib/libc_nonshared.a(stat.oS) is referenced by DSO collect2: ld returned 1 exit status make: *** [ctxhx] Error 1 Click ignore. This is fixed by applying the 9.2.0.4 patchset. Patching Oracle9iR2 on RH AS 3 To patch Oracle9iR2, download the Oracle 9i Release 2 Patch Set 3 Version 9.2.0.4.0 for Linux x86 from http://metalink.oracle.com. Copy the downloaded "p3095277_9204_LINUX.zip" file to e.g. /tmp and run the following command: su - oracle $ cp p3095277_9204_LINUX.zip /tmp $ cd /tmp $ unzip p3095277_9204_LINUX.zip Archive: p3095277_9204_LINUX.zip inflating: 9204_lnx32_release.cpio inflating: README.html inflating: patchnote.css $ $ cpio -idmv < 9204_lnx32_release.cpio Disk1/stage/locks Disk1/stage/Patches/oracle.apache.isqlplus/9.2.0.4.0/1/DataFiles/bin.1. 1.jar Disk1/stage/Patches/oracle.apache.isqlplus/9.2.0.4.0/1/DataFiles/lib.1. 1.jar ... To patch the runInstaller, run: su - oracle $ echo $LD_ASSUME_KERNEL set! 2.4.1 $ cd /tmp/Disk1/ $ ./runInstaller !" Welcome Screen: File Locations: Available Products: # it is important that this variable is Click Next Use default values Select "Oracle Universial Installer 2.2.0.18.0 Components Locations: Accept default values and click Next Summary: Start the Install At the end of the installation, you must exit runInstaller! To patch Oracle9iR2, run: su - oracle $ echo $LD_ASSUME_KERNEL set! 2.4.1 $ cd $ORACLE_HOME/bin $ ./runInstaller - Welcome Screen: - File Locations: - Available Products: # it is important that this variable is Click Next Use default values Select "Oracle9iR2 Patch Set 3 9.2.0.4.0 !" - Summary: Start the Install - At the end of the installation, exit runInstaller You may get the following error: Error in invoking target install of makefile /u01/app/oracle/product/9.2.0/network/lib/ins_oemagent.mk. The /u01/app/oracle/product/9.2.0/install/make.log file reads: /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcl.o)(.text+0x1 cc): In function `get_ora_stmt_handle': : undefined reference to `__ctype_b' /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcl.o)(.text+0x1 24e): In function `OraProcess_Oid': : undefined reference to `__ctype_b' /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcl.o)(.text+0x1 76c): more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status make: *** [dbsnmp] Error 1 Click ignore. This will be fixed by applying the patch 3119415 after the 9.2.0.4 patchset has been applied. The patch 3119415 cannot be applied while the patch process for the 9.2.0.4 patchset is running. After the 9.2.0.4 patchset has been applied, download the patch p3119415_9204_LINUX.zip from http://metalink.oracle.com. See bug 3119415 for more information. Also, download the opatch Release 2.2.0 utility from http://metalink.oracle.com. See bug 2617419 for more information. To install opatch, run: su - oracle $ cp p2617419_210_GENERIC.zip /tmp $ cd /tmp $ unzip p2617419_210_GENERIC.zip Before you apply the 3119415 patch, you need to make sure the fuser binary can be found by the oracle user, see the PATH environment variable below. Otherwise the patch can't be applied because the fuser binary is used by opatch. To apply the 3119415 patch, run su - oracle $ unzip p3119415_9204_LINUX.zip $ cd 3119415 $ export PATH=$PATH:/tmp/OPatch $ export PATH=$PATH:/sbin located in /sbin $ which opatch /tmp/OPatch/opatch $ opatch apply # the patch needs "fuser" which is Now you should be able to create a database with dbca: su - oracle dbca Patching Oracle Intelligent Agent on RH AS 3 When you run "agentctl start" (Oracle 9.2.0.4), dbsnmp will crash: $ su - oracle $ agentctl start DBSNMP for Linux: Version 9.2.0.4.0 - Production on 07-JAN-2004 19:11:14 Copyright (c) 2003 Oracle Corporation. All rights reserved. 1855 Starting Oracle Intelligent Agent.../u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 /u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1868 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 /u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1880 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 /u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1892 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 To resolve this problem, apply the patch p3238244_9204_LINUX.zip from http://metalink.oracle.com. See bug/patch 3238244 for more information. Before you apply the patch, make sure the instance is down! Also make sure the opatch script appears in your $PATH. See "Patching Oracle9iR2 on Red Hat AS 3" for information on getting and installing opatch. To verify if opatch is in your $PATH, run the which command: $ su - oracle $ which opatch /tmp/OPatch/opatch $ To apply now the patch, run: $ su - oracle $ unzip p3238244_9204_LINUX.zip $ cd 3238244 $ export PATH=$PATH:/sbin located in /sbin $ opatch apply # the patch needs "fuser" which is Now you need to relink dbsnmp. This is the binary that crashed when running agentctl start. To find which makefile handles the linking of dbsnmp, you can run: $ su - oracle $ find $ORACLE_HOME -name "*.mk" | xargs grep -l dbsnmp /u01/app/oracle/product/9.2.0/network/lib/ins_oemagent.mk /u01/app/oracle/product/9.2.0/network/lib/env_oemagent.mk $ I relinked dbsnmp and all associated executables which are maintained by the ins_oemagent.mk makefile: $ su - oracle $ cd $ORACLE_HOME/network/lib $ make -f ins_oemagent.mk install Now you should be able to start the agent: $ su - oracle $ agentctl start NOTE: Don't forget to undo the changes (links) to /usr/bin/gcc and /usr/bin/g++ if you don't need it any more. Also don't forget the /etc/ld.so.preload file. Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 4 In order to install Oracle9i Release 2 (9.2.0.6) I've applied the 9.2.0.6 patch set for the Oracle database server (patch number 3948480) after the Oracle9i Release 2 (9.2.0.4) installation. For more information, see Oracle9i Release Notes Release 2 (9.2.0.4.0) for Linux x86 - Red Hat Enterprise Linux 4 Certification Update. Installing Oracle9iR2 on RH AS 4 Before you continue, ensure all the required RPMs are installed, see Packages (RPMs) for Red Hat Enterprise Linux Advanced Server 4 (RHEL AS 4). Also ensure LD_ASSUME_KERNEL is set to 2.4.19 (see Setting Oracle Environments): $ su - oracle $ echo $LD_ASSUME_KERNEL 2.4.19 $ Now launch runInstaller: su - oracle $ echo $LD_ASSUME_KERNEL 2.4.19 $ /media/cdrom/runInstaller - Welcome Screen: - Inventory Location: - Unix Group Name: Click Next Click OK Use "oinstall" and click Next When asked to run /tmp/orainstRoot.sh, run it before you click Continue - File Locations: Use default values - Available Products: Select "Oracle9i Database 9.2.0.4.0" - Installation Types: Select Custom since we only want to install the software for now - Available Products: Click Next or add some more components. - Components Locations: Accept default values and click Next - Privileged Operating System Groups: I used the default values: OSDBA Group = dba, OSOPER Group = dba - Oracle Managent Server Repository: I used the default choice - Create database: Select NO since we first need to patch Oracle database software! - Summary: Start the Install Patching Oracle9i R2 (9.2.0.4) on RH AS 4 Download the patch 3948480 (Oracle9i Patch Set Release 2 (9.2.0.6) Patch Set 5) from http://metalink.oracle.com and execute the following commands: su - oracle $ cp p3948480_9206_LINUX.zip /tmp $ cd /tmp $ unzip p3948480_9206_LINUX.zip Archive: p3948480_9206_LINUX.zip creating: Disk1/ creating: Disk1/stage/ creating: Disk1/stage/Patches/ ... Now download the patch 4188455 from http://metalink.oracle.com. This patch is needed for launching the runInstaller that came with the patch 3948480 we just downloaded above. su - oracle $ cp p4188455_10103_LINUX.zip /tmp $ cd /tmp $ unzip p4188455_10103_LINUX.zip Archive: p4188455_10103_LINUX.zip inflating: oraparam.ini inflating: README.txt $ The /tmp/oraparam.ini file will now be used for launching the runInstaller that came with the patch 3948480. To patch the runInstaller itself, run: su - oracle $ echo $LD_ASSUME_KERNEL 2.4.19 $ /tmp/Disk1/install/runInstaller -paramFile /tmp/oraparam.ini - Welcome Screen: Click Next - File Locations: Use default values (in my example: /tmp/Disk1/stage/products.xml) - Available Products: Select "Oracle Universial Installer 10.1.0.3.0 !" - Summary: Click Install - At the end of the installation, you must exit runInstaller! Ensure that no Oracle processes are running: ps -ef | grep ora Now to patch Oracle9iR2, run: su - oracle $ echo $LD_ASSUME_KERNEL # it is important that this variable is set! 2.4.19 $ /tmp/Disk1/install/runInstaller -paramFile /tmp/oraparam.ini - Welcome Screen: Click Next - File Locations: Use default values (in my example: /tmp/Disk1/stage/products.xml) - Available Products: Select "Oracle 9iR2 Patchset 9.2.0.6.0" - Summary: Click Install When are asked to run root.sh, run it before you click Continue - At the end of the installation, exit runInstaller. After the 9.2.0.6 patchset has been applied, download the patch 4190568 from http://metalink.oracle.com. Also, download the opatch utility for release 10.1.0.2 (patch 2617419) from http://metalink.oracle.com. To install opatch, run: su - oracle $ cp p2617419_10102_GENERIC.zip /tmp $ cd /tmp $ unzip p2617419_10102_GENERIC.zip $ cp -a /tmp/OPatch/ $ORACLE_HOME To apply the 4190568 patch, run su - oracle $ unzip p4190568_9206_LINUX.zip $ cd 4193454 $ export PATH=$PATH:$ORACLE_HOME/OPatch $ opatch apply If you intend to use Direct I/O Support, you must also download and apply patch 2448994. Now you should be able to create a database with dbca: su - oracle dbca When dbca died on my system with the following error: /u01/app/oracle/product/9.2.0/bin/dbca: line 124: 26649 Segmentation fault $JRE_DIR/bin/jre -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m classpath $CLASSPATH oracle.sysman.assistants.dbca.Dbca $ARGUMENTS I executed the following command: su - root touch /etc/rac_on and restarted dbca. If you know a better solution, let me know! Startup and Shutdown of the Oracle 9i Database sqlplus: svrmgrl is not supported any more. You can now do everything with sqlplus. For instance, to startup the database, run the following commands: oracle$ sqlplus /nolog SQL> connect / as sysdba SQL> startup The slash connects you to the schema owned by SYS. So in this example you will be connected to the schema owned by SYS with the privilege SYSDBA. SYSDBA gives you the following privileges: - sysoper privileges WITH ADMIN OPTION - create database - recover database until $ORACLE_HOME/bin/dbstart and $ORACLE_HOME/bin/dbshut You can also use $ORACLE_HOME/bin/dbstart to startup the database, and $ORACLE_HOME/bin/dbshut to shutdown the database. You can place $ORACLE_HOME/bin/dbstart into the /etc/rc.d/rc.local boot script to automatically bring up the database at system boot time. To get $ORACLE_HOME/bin/dbstart and $ORACLE_HOME/bin/dbshut working, you need to change the third field for your Oracle SID in /etc/oratab from "N" to "Y". For example, for the Oracle SID "test" I changed the line in /etc/oratab from: test:/u01/app/oracle/product/9.2.0:N to read: test:/u01/app/oracle/product/9.2.0:Y In some cases for 9.2.0 I also had to copy the init file for my SID "test" from /u01/app/oracle/admin/test/pfile to $ORACLE_HOME/dbs to get dbstart and dbshut working: cp /u01/app/oracle/admin/test/pfile/inittest.ora.642002224936 $ORACLE_HOME/dbs/inittest.ora But first make sure if your init file already exists in $ORACLE_HOME/dbs! Oracle Installation Problems, Tips and Hints Some of these problems apply only to 9.0.1!  Do not cd to /mnt/cdrom to run ./runInstaller! If you do so, the installation will fail because you won't be able to change the CDs.  If you forgot to set the DISPLAY environment variable (e.g. export DISPLAY=oracleserver:0.0), or if you forgot to give the remote console - your Oracle Server - authority to display X information on your desktop PC (e.g. xhost +oracleserver), then you will get the following error: Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server In this case, I always had to kill runInstaller in Oracle9iR1 (9.0.1) which was still running in the background. If I didn't do this in 9.0.1, runInstaller didn't completely come up any more without displaying any error messages. You might also want to clean up /tmp/OraInstall.  When runInstaller starts to configure the tools ("Configuration Tools"), the "Oracle Net Configuration Assistant" will sometimes hang. Simply stop the Assistant and restart it, or continue the installation. When the rest of the installation is finished, do a "Retry" for "Oracle Net Configuration Assistant". This always worked for me. When the system stops responding during the Oracle installation in particular during the database creation, then that's probably because you don't have enough RAM or enough swap space. I saw the whole system not responding or to "hang" for several minutes when I did not have enough swap space. If this happens, simply wait until the system starts to respond again. The Oracle installation also runs make etc. In a production environment you might not have compilers and other development packages installed. Therefore make sure you have temporarily the following packages installed: gcc, cpp, glibc-devel, compat-libstdc++, kernel-headers (for RH 7.1, 7.2, 2.1AS), glibc-kernheaders (for RH 7.3, 8.0, 9.0), binutils. See also Checking Packages (RPMs) for more information. If for any reason the Oracle9i installation didn't finish successfully, you might want to clean up the following files and directories before you start over again: /etc/oraInst.loc /etc/oratab /tmp/ $ORACLE_BASE/*     Other Problems: You might want to check out the Oracle on Linux Discussion Forum. Oracle Installation Errors Here is a list of Oracle 9i (9.0.1 & 9.2.0) installation problems and issues. Some issues, errors, problems, and solutions apply only to 9.0.1 and some only to 9.2.0. Since I did not experience all of the problems here, I am not able to verify the correctness of all the solutions. However, I experienced most of the problems listed here. If you had other problems and you were able to resolve them, please drop me an email at webmaster_at_puschitz.com. Here is a list of issues issues, errors, problems and solutions:  Log Files First check always the error logs for 9.2.0 in /tmp/OraInstall (e.g /tmp/OraInstall2002-07-04_09-50-19PM), and for 9.0.1 in /tmp/OraInstall. When you get make problems, check also the file $ORACLE_HOME/install/make.log.  "Various make Problems" Make sure that gcc is installed on your system: $ which gcc /usr/bin/gcc Here is the command to find the RPM package name for /usr/bin/gcc: $ rpm -qf /usr/bin/gcc gcc-2.96-98 Check also the other error messages below. See also Checking Packages (RPMs) for more information.  "Error in invoking target install of makefile /u01/app/oracle/product/9.2.0/ctx/lib/ins_ctx.mk" I saw this error only when I installed Oracle9iR2 (9.2.0). This was also the only problem I experienced with Oracle 9i R2 on Red Hat 8.0. However, this does not necessarily mean that you won't experience other problems described here. When I had this problem, the following errors showed up in $ORACLE_HOME/install/make.log: /lib/libdl.so.2: undefined `_dl_addr@GLIBC_PRIVATE' /lib/libdl.so.2: undefined `_dl_open@GLIBC_PRIVATE' /lib/libdl.so.2: undefined `_dl_close@GLIBC_PRIVATE' /lib/libdl.so.2: undefined `_dl_sym@GLIBC_PRIVATE' /lib/libdl.so.2: undefined `_dl_vsym@GLIBC_PRIVATE' reference to reference to reference to reference to reference to This error comes up when the following step is executed: /usr/bin/make -f ins_ctx.mk install ORACLE_HOME=/u01/app/oracle/product/9.2.0 Edit the file $ORACLE_HOME/ctx/lib/env_ctx.mk, go to "INSO_LINK =", and add a "$(LDLIBFLAG)dl" to the line and save it. Here is the full line with the added "$(LDLIBFLAG)dl" flag: INSO_LINK = -L$(CTXLIB) $(LDLIBFLAG)m $(LDLIBFLAG)dl $(LDLIBFLAG)sc_ca $(LDLIBFLAG)sc_fa $(LDLIBFLAG)sc_ex $(LDLIBFLAG)sc_da $(LDLIBFLAG)sc_ut $(LDLIBFLAG)sc_ch $(LDLIBFLAG)sc_fi $(LLIBCTXHX) $(LDLIBFLAG)c -Wl,rpath,$(CTXHOME)lib $(CORELIBS) $(COMPEOBJS) After that hit retry in the error popup. If this didn't work, then try the following: Edit the file $ORACLE_HOME/ctx/lib/env_ctx.mk again, go to "INSO_LINK =", remove the above entry you made and add a "`cat $(LIBHOME)/sysliblist`" to the line and save it. Here is the full line with the added "`cat $(LIBHOME)/sysliblist`" string: INSO_LINK = -L$(CTXLIB) $(LDLIBFLAG)m `cat $(LIBHOME)/sysliblist` $(LDLIBFLAG)sc_ca $(LDLIBFLAG)sc_fa $(LDLIBFLAG)sc_ex $(LDLIBFLAG)sc_da $(LDLIBFLAG)sc_ut $(LDLIBFLAG)sc_ch $(LDLIBFLAG)sc_fi $(LLIBCTXHX) $(LDLIBFLAG)c -Wl,-rpath,$(CTXHOME)lib $(CORELIBS) $(COMPEOBJS) After that hit retry in the error popup.  ORA-27123: unable to attach to shared memory segment. I saw this error only when I installed Oracle 9i R2 (9.2.0). This error message came up when the Oracle Database Configuration Assistant was running. I executed the following command to temporarily increase the maximum shared memory size: su - root # cat /proc/sys/kernel/shmmax 33554432 # echo `expr 1024 \* 1024 \* 1024` > /proc/sys/kernel/shmmax # cat /proc/sys/kernel/shmmax 1073741824 # Then click "Retry" for the Oracle Database Configuration Assistant. It is recommended to increase the shmmax setting permanently for Oracle9i. So if you want to increase the maximum shared memory size permanently, add the following line to the /etc/sysctl.conf file: kernel.shmmax=1073741824 For more information on setting shared memory parameters for Oracle, see Setting Shared Memory.  ORA-03113: end-of-file on communication channel I saw this error when I've run the "Database Configuration Assistant" and "sqlplus". When the "Database Configuration Assistant" gave me this error during Oracle9iR2 (9.2.0) installation on Red Hat 2.1 AS, I simply removed the shared memory segments owned by the Oracle user and I restarted the "Database Configuration Assistant". I'm not sure if this is the right way but it always worked for me. Here is what I did to get the "Database Configuration Assistant" running again: Database Configuration Assistant: I executed the ipcs command to get the address of the shared memory segments that have been allocated by Oracle: $ su - root # ipcs ------ Shared Memory Segments -------key shmid owner perms nattch status 0x00000000 0 root 600 0x00000001 32769 root 600 0x00000000 458755 oracle 660 0x00000000 491524 oracle 660 0x00000000 524293 oracle 660 0x00000000 557062 oracle 660 0x00000000 589831 oracle 660 0x00000000 622600 oracle 660 0x00000000 655369 oracle 660 0x00000000 688138 oracle 660 0x3ecee0b0 720907 oracle 660 ------ Semaphore Arrays -------bytes 196608 655360 4194304 33554432 33554432 33554432 33554432 33554432 33554432 33554432 4194304 2 2 0 0 0 0 0 0 0 0 0 key status semid owner perms nsems ------ Message Queues -------key msqid owner messages # perms used-bytes Then I removed all shared memory segments that were owned by the Oracle user during the installation with the following command: # ipcrm shm 458755 491524 524293 557062 589831 622600 655369 688138 720907 After that I restarted the "Database Configuration Assistant". Once the installation was done I immediately restarted the DB as well. Caveat: I'm not sure if this procedure can cause any further problems if this is done during the installation. But so far I haven't seen any issues with this approach. sqlplus: If you get this problem in connection with sqlplus, then simply make sure that the database is down and exit sqlplus. After that, follow the procedure above by removing all shared memory segments that belong to the Oracle user. To my knowledge, this should not cause any problems. For more information on shared memory segments, see Determining Which Semaphore Sets and Shared Memory Segments Belong to Each Oracle Database or Instance. NOTE: To solve this problem permanently, increase the kernel shmmax size. For more information, see Setting Shared Memory and Setting Shared Memory.  "Error invoking target install of makefile /u01/app/oracle/product/9.0.1/plsql/lib/ins_plsql.mk" "Error invoking target install of makefile /u01/app/oracle/product/9.0.1/precomp/lib/ins-precomp.mk" "Error invoking target install of makefile /u01/app/oracle/product/9.0.1/precomp/lib/ins-net-client" I saw this error only when I installed Oracle 9i (9.0.1). People have sent me emails pointing out that the following solution also works for Mandrake 8.1, Mandrake 8.2, and for SuSE 8.0. Edit the file $ORACLE_HOME/bin/genclntsh and change the following line: LD_SELF_CONTAINED="-z defs" to read: LD_SELF_CONTAINED="" After that run the script $ORACLE_HOME/bin/genclntsh as the user "oracle" and not as the user "root". Also make sure you have all the Oracle environments set correctly! $ su - oracle $ $ORACLE_HOME/bin/genclntsh Created /u01/app/oracle/product/9.0.1/lib/libclntst9.a $ After that hit Retry in the error dialog window. This always worked for me. Here is Oracle's official solution for Oracle 9iR1 and 9iR1 iAS on RedHat 2.1 Advanced Server: http://otn.oracle.com/software/products/oracle9i/files/binutils_readme.htm l  "Error in invoking target install of make file /u01/app/oracle/product/9.2.0/network/lib/ins_oemagent.mk" If you see this error on Red Hat Enterprise Linux 3, follow the guideline at Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 3. On Red Hat 9 I performed the following steps here when the ORACLE_HOME/install/make.log file contained the error messages: ... /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln .o)(.text+0x159d): In function `Nls_ScanCmd': : undefined reference to `__ctype_b' /u01/app/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln .o)(.text+0x1603): more undefined references to `__ctype_b' follow The issue here is that __ctype_b() is actually gone for __ctype_b_loc() because Red Hat uses a new locale model. However, in libc.so, __ctype_b is still exported as compatibility symbol; at least that's the case with RH 9 glibc-2.3.2-5. And here is the reason why some people have this problem with Red Hat 9 and why some don't: When you bought the Red Hat 9 CDs in a store, then you will probably find glibc-2.3.2-5.i686.rpm on the first CD. This glibc version exports __ctype_b(): $ rpm -ql glibc-2.3.2-5 | grep libc.so /lib/i686/libc.so.6 /lib/libc.so.6 /lib/tls/libc.so.6 $ nm -a /lib/i686/libc.so.6 | grep __ctype_b 001315f8 D __ctype_b 00022340 T __ctype_b_loc $ nm -a /lib/libc.so.6 | grep __ctype_b 00133c58 D __ctype_b 000223a0 T __ctype_b_loc $ But when you downloaded Red Hat 9 from redhat.com or from one of the mirror sites, then you will find glibc-2.3.2-11.9.i686.rpm on the image. This glibc version does not export __ctype_b(). This is also the case with glibc-devel-2.3.2-27.9.i386.rpm. $ rpm -ql glibc-2.3.2-11.9 | grep libc.so /lib/i686/libc.so.6 /lib/libc.so.6 /lib/tls/libc.so.6 $ nm -a /lib/i686/libc.so.6 | grep __ctype_b 00131718 D __ctype_b@GLIBC_2.0 000223a0 T __ctype_b_loc $ nm -a /lib/libc.so.6 | grep __ctype_b 00133d58 D __ctype_b@GLIBC_2.0 000223f0 T __ctype_b_loc $ Check the glibc version on your system: First check if the glibc packages on your RH 9 system work with the Oracle installer: $ rpm -q glibc-2.3.2-5 glibc-common-2.3.2-5 glibc-devel2.3.2-5 If you got the following error mesages: package glibc-2.3.2-5 is not installed package glibc-common-2.3.2-5 is not installed package glibc-devel-2.3.2-5 is not installed then you have glibc packages on your system that don't work with the Oracle installer and you need to follow the "Work Around" procedure here. But if your system has the 2.3.2-5 glibc versions installed, then you are fine and you don't need to follow the described "Work Around" procedure! Work Around Procedure: Since I was not able to find the glibc-2.3.2-5 RPMs available for download, I'm making the RPMs available on my website. These RPMs are copies of the glibc RPMs that came with the RH 9 CDs I bought in the store. I do not recommend to use any of the "compat" RPMs from older Red Hat distributions since RH 9 contains major changes. Here is the procedure for installing glibc-2.3.2-5 temporarely on your RH 9 server: Download the 2.3.2-5 glibc RPMs from here on my web site. First make sure if these downloaded RPM's are not corrupt and if they were really built and signed by Red Hat. You never know if someone fiddled with these RPMs or replaced them. To ensure the integrity and origin of these Red Hat's RPMs, run the following commands: $ su - root # rpm --import /usr/share/rhn/RPM-GPG-KEY # add Red Hat's PGP public key to the RPM database # rpm --checksig glibc-2.3.2-5.i686.rpm glibc-common2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm glibc-2.3.2-5.i686.rpm: (sha1) dsa sha1 md5 gpg OK glibc-common-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK glibc-devel-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK # Downgrade glibc, glibc-common, and glibc-devel: # rpm -Uvh --oldpackage glibc-2.3.2-5.i686.rpm glibccommon-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm If you get the following error: error: Failed dependencies: glibc = 2.3.2-11.9 is needed by (installed) glibcdebug-2.3.2-11.9 glibc = 2.3.2-11.9 is needed by (installed) glibcutils-2.3.2-11.9 glibc-devel = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9 glibc-devel = 2.3.2-11.9 is needed by (installed) nptl-devel-2.3.2-11.9 then you can temporarily remove these RPMs (glibc-debug, glibc-utils, nptl-devel) from your system until you upgrade the glibc RPMs after your Oracle installation: # rpm -e glibc-debug glibc-utils nptl-devel Now try to run runInstaller again. After Oracle has been installed, you can upgrade glibc, glibc-common, and glibc-devel again. For example: # rpm -Uvh glibc-2.3.2-11.9.i686.rpm glibc-common-2.3.211.9.i386.rpm glibc-devel-2.3.2-11.9.i386.rpm According to Red Hat, binary compatibility in Red Hat Linux is always guaranteed for binaries and shared libraries accross releases, but not for .o files nor .a files. However, compatibility is guaranteed for .o files and .a files. _within_ a realease. Since glibc-2.3.2-5 and glibc-2.3.2-11.9 are from the same release, compatibility should be guaranteed for .o files (Oracle's .o files which have been created during the Oracle installation) and .a files. This means that Oracle should be fine when you upgrade glibc after the Oracle installation. If you have any problems or issues with this solution, or if you have any comments, please let me know. You can find my email address at the bottom of this web site.             $ agentctl start DBSNMP for Linux: Version 9.2.0.4.0 - Production on 07-JAN-2004 19:11:14 Copyright (c) 2003 Oracle Corporation. All rights reserved. Starting Oracle Intelligent Agent.../u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1855 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 /u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1868 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 /u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1880 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 /u01/app/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1892 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >>$DBSNMP_WDLOGFILE 2>&1 You are probably trying to start the agent on RH AS 3. See Patching Oracle Intelligent Agent on RH AS 3 how to resolve it.          $ dbca SIGSEGV 11* segmentation violation stackbase=0x453da000, stackpointer=0x453d9d5c Full thread dump: "AWT-EventQueue-0" (TID:0x411d1e20, sys_thread_t:0x453d9e0c, state:R) prio=5 *current thread* java.lang.Object.wait(Object.java) java.awt.EventQueue.getNextEvent(EventQueue.java:126) ... Or on e.g. RHEL4: /u01/app/oracle/product/9.2.0/bin/dbca: line 124: 26649 Segmentation fault $JRE_DIR/bin/jre -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m classpath $CLASSPATH oracle.sysman.assistants.dbca.Dbca $ARGUMENTS If this happens, try the following: $ su - root touch /etc/rac_on Now try to restart dbca. Another option is to edit $ORACLE_HOME/bin/dbca and to put the following lines under comment except the line marked in blue: # if [ -f /etc/rac_on ]; then # Run DBCA $JRE_DIR/bin/jre -native -DORACLE_HOME=$OH ... # else # Run DBCA # $JRE_DIR/bin/jre -DORACLE_HOME=$OH ... # fi Now try to restart dbca.       1 gcc -o /u01/app/oracle/product/9.2.0/rdbms/lib/oracle L/u01/app/oracle/product/9.2.0/rdbms/lib/ ... ... /usr/bin/ld: /u01/app/oracle/product/9.2.0/rdbms/lib/oracle: hidden symbol `__fixunssfdi' in /usr/lib/gcc-lib/i386-redhatlinux/3.2.3/libgcc.a(_fixunssfdi.oS) is referenced by DSO collect2: ld returned 1 exit status make: *** [/u01/app/oracle/product/9.2.0/rdbms/lib/oracle] Error   /usr/bin/make -f ins_rdbms.mk ioracle ORACLE_HOME=/u01/app/oracle/product/9.2.0 I've seen this error on RH AS 3. To fix the linking problem, I executed the following commands: # # # # mv mv ln ln /usr/bin/gcc /usr/bin/gcc323 /usr/bin/g++ /usr/bin/g++323 -s /usr/bin/gcc296 /usr/bin/gcc -s /usr/bin/g++296 /usr/bin/g++ Now you should be able to relink the oracle binary again. Once you are done, make sure to revert back the changes you've made above: # mv /usr/bin/gcc323 /usr/bin/gcc # mv /usr/bin/g++323 /usr/bin/g++  ./runInstaller: line 58: ./runInstaller: cannot execute binary file. You are probably trying to run a 64-bit Oracle version on a 32-bit Linux system. Make sure you downloaded the right Oracle version for your Linux system. To check if runInstaller is a 32-bit binary or a 64-bit binary, run the following command: $ cd /mnt/cdrom $ file install/linux/runInstaller install/linux/runInstaller: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped To check if your Linux system is 32-bit system or a 64-bit system, run e.g. the following command: $ file /sbin/init /sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped  The Oracle installer runInstaller hangs at: Installing Java Runtime Environment... Link pending... Copying README... This problem comes up on RH 9 and on RH AS 3. You probably forgot to set the environment variable LD_ASSUME_KERNEL to 2.4.1. To rectify this problem, run the following command and restart runInstaller: oracle$ export LD_ASSUME_KERNEL=2.4.1 For more information on this issue, see Red Hat 9.  Recovery Manager rman hangs You are probably running the wrong rman binary which belongs to the XFree86-devel RPM: $ which rman /usr/X11R6/bin/rman  Can't find init file for Database "SID". I saw this error only with Oracle 9i R2 (9.2.0) when It tried to start the database with dbstart. I copied the init file for my SID "test" from /u01/app/oracle/admin/test/pfile to $ORACLE_HOME/dbs to get dbstart and dbshut working: cp /u01/app/oracle/admin/test/pfile/inittest.ora.642002224936 $ORACLE_HOME/dbs/inittest.ora  "Error in setting permissions of file/directory /u01/app/oracle/jre/1.1.8/bin/i686/native_threads/.extract_args" This happens if you didn't burn your CD correctly. Either you burn your CD again to include dot files or you copy the .extract_args file from your downloaded image to where runInstaller complains it is missing.      ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist Linux Error: 2: No such file or directory or ORA-01034: ORACLE not available  First check if ORACLE_SID is set correctly. If ORACLE_SID is set correctly, then you probably have a trailing slash "/" on the ORACLE_HOME environment variable. Remove it and try again to connect to sys (e.g from ORACLE_HOME=/u01/app/oracle/product/9.2.0/ to ORACLE_HOME=/u01/app/oracle/product/9.2.0).  "jre was not found in /tmp/OraInstall/jre/bin/i586/green_threads/jre" You are probably running runInstaller on a 586 machine, or your AMD CPU gets recognized as 586 (e.g. AMD K6-III-400). You can check your machine (hardware) type by executing "uname -m". If you are not running on a 586 or on a AMD machine, try to link jre to java and see if this solves your problem. To rectify the problem with the 586 machine or with the AMD CPU, create a link for lib and bin from i586 to i686 and make the i686 directories read only. For example: ln -s /tmp/OraInstall/jre/bin/i686 /tmp/OraInstall/jre/bin/i586 ln -s /tmp/OraInstall/jre/lib/i686 /tmp/OraInstall/jre/lib/i586 chmod u-w /tmp/OraInstall/jre/bin/i686/tmp/OraInstall/jre/lib/i686 Now restart runInstaller.  ../jre/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory You probably forgot to install the compat-libstdc++ RPM which is a package for "Standard C++ libraries for Red Hat Linux 6.2 backwards compatibility". To rectify this problem, install the compat-libstdc++ RPM. For example on Red Hat 9: rpm -ivh compat-libstdc++-7.3-2.96.118.i386.rpm See also Checking Packages (RPMs) for more information.  /u01/app/oracle/jre/1.1.8/bin/../lib/i686/green_threads/libzip.so : symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference (libzip.so) Unable to initialize threads: cannot find class java/lang/Thread Could not create Java VM I experienced this problem when I was running the Database Configuration Assistant dbca on Red Hat 9 without setting the LD_ASSUME_KERNEL environment variable. To rectify this problem, run the following command on Red Hat 9 and RHEL 3 and restart dbca: oracle$ export LD_ASSUME_KERNEL=2.4.1 For more information on this issue, see Red Hat 9.                 $ lsnrctl start OR $ lsnrctl status LSNRCTL for Linux: Version 9.2.0.4.0 - Production on 14-OCT-2004 14:33:10 Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC))) TNS-12541: TNS:no listener TNS-12560: TNS:protocol adapter error TNS-00511: No listener Linux Error: 2: No such file or directory Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=1521))) TNS-12541: TNS:no listener TNS-12560: TNS:protocol adapter error TNS-00511: No listener Linux Error: 111: Connection refused One of the possibilities are that the /var/tmp/.oracle directory doesn't exist. This happened with fresh new Oracle 9.2.0.4.0 CDs on RH AS 3. If that's the case, run the following commands: su - root mkdir /var/tmp/.oracle chown oracle:dba /var/tmp/.oracle Now try to run lsnrctl start as oracle again.    Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using 'alpha:0.0' as the value of the DISPLAY variable. at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:59)         at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(Graphics Environment.java:58) at java.awt.Window.(Window.java:188) at java.awt.Frame.(Frame.java:315) at java.awt.Frame.(Frame.java:262) at oracle.sysman.oii.oiic.OiicInstaller.main(OiicInstaller.java:593) Ensure you followed the instructions at Starting runInstaller very closely. NOTE: If you use for example Red Hat Fedora Core 3 as your desktop and you want to install the database on another machine, then you need to set the DisallowTCP entry in /etc/X11/gdm/gdm.conf for the GNOME Display Manager to read: DisallowTCP=false After that you need to restart your X server. I usually do this with the init command: su - root init 3 init 5 Tuning and Optimizing Red Hat Linux Advanced Server for Oracle 9i Databases The following procedure is a step-by-step guide with tips and information for tuning and optimizing Red Hat Linux Advanced Server 2.1 for Oracle9i databases. This HOWTO shows how I tuned and optimized Red Hat AS 2.1 for Oracle 9iR2 (9.2.0). A procedure for installing Oracle9iR2 on Red Hat AS 2.1 can be found at here. Note that many tuning steps in this article also apply to other Linux distributions and releases. This article covers the following subjects and steps: * Introduction * Oracle Limits on Linux * Why Using Red Hat Advanced Server 2.1 * Upgrading the Linux Kernel * Sizing Swap Space Swap Size Recommendations Checking Physical Memory Checking Swap Space Size and Usage * Setting Shared Memory Setting SHMMAX Parameter Setting SHMMNI Parameter Setting SHMALL Parameter * Setting Semaphores The SEMMSL Parameter The SEMMNI Parameter The SEMMNS Parameter The SEMOPM Parameter Setting the Semaphore Kernel Parameters * Setting File Handles * Setting Shell Limits for the Oracle User Setting Limits for the Maximum Number of Open File Descriptors for the Oracle User Setting Limits for the Maximum Number of Processes for the Oracle User * Setting Asynchronous I/O Relinking Oracle to Enable Asynchronous I/O for Oracle9iR2 Enabling Asynchronous I/O in init.ora for Raw Devices Enabling Asynchronous I/O in init.ora for Filesystem Files Increasing I/O Throughput at the Linux OS Level * Increasing Space for Larger SGA (2.7 GB) to Fit Into Memory Address Mappings on Linux - Shared Memory and Shared Library Mapping on Linux Changing the Base Address "mapped base" for Shared Libraries at the Linux OS Level Changing the Base Address for Shared Memory at the Oracle Level Giving Oracle Users the Privilege to Change the Base Address for Oracle's Shared Libraries Without Giving them root Access Changing the Base Address for Oracle's Shared Libraries Automatically During an Oracle Login Important Notes * Using Large Memory Pages (Bigpages) Sizing Bigpages Configuring Bigpages * Making Other Performance Related Changes Disabling Unneeded Background Processes * Oracle Errors and Problems * Useful Linux Performance Utilities top Utility sar Utility vmstat Utility * Oracle Linux Management Determining Which Semaphore Sets and Shared Memory Segments Belong to Each Oracle Database or Instance Finding and Removing Oracle IPC Resources Easily * Hardware Recommendation * References Introduction Please point out every error you can find. I welcome email from any readers with comments, suggestions, or corrections. My address is webmaster_at_puschitz.com. I will continue to update and add new information for this article. So make sure to come back. :) Before you begin making any changes to the Linux systems, make sure that the Oracle database is down! Oracle Limits on Linux Some limits apply to Red Hat Advanced Server only. Linux supports 64-bit file I/O on 32-bit Intel platforms. According to the white paper Oracle9iR2 on Linux: Performance, Reliability and Manageability Enhancements on Red Hat Linux Advanced Server 2.1", the limits are as follows: - Number of files per database: 64K - Number of blocks per file: 4 million - Maximum block size: 16 KB - Maximum size for a database file is 64 GB - Maximum database size is 4 petabytes with 16 KB blocks 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. Why Using Red Hat Advanced Server 2.1 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 Upgrading the Linux Kernel 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=idescsi 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 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. Sizing Swap Space In order to perform a typical Oracle 9i installation and to create a simple prototype database, Oracle says that you need a minimum of 512MB of RAM for the Oracle9i Server, and the amount of swap space should be equal to twice the amount of RAM or at least 400 MB, whichever is greater. Oracle also says that the minimum swap space should be at least the same as physical memory size. Swap Size Recommendations To summarize Oracle's recommendation for the database and to take system configurations into account that were used for workload testings, here is what I came up with: 0.5 GB RAM 1 GB - 2 GB Swap Space 1 GB RAM 2 GB - 3 GB Swap Space 2 GB RAM 2 GB - 3 GB Swap Space 3 GB RAM 3 GB Swap Space 4 GB RAM 4 GB Swap Space 8 GB RAM 4 GB Swap Space 16 GB RAM 8 GB Swap Space The swap space will not be utilized until the system runs out of physical memory. So don't configure too much swap space. Keep in mind that if the system starts using swap space, it has a negative impact to the performance of the database. So make sure that the system has always enough physical RAM and that it doesn't use swap space continuously. Checking Physical Memory You can check the size of physical memory by running the following command: grep MemTotal /proc/meminfo You can find a detailed description of the entries in /proc/meminfo at http://www.redhat.com/advice/tips/meminfo.html. Alternatively, you can use free(1) to check the memory: # free total cached Mem: 1031004 287388 -/+ buffers/cache: Swap: 2097144 # used 734656 184864 40184 free 296348 846140 2056960 shared 0 buffers 262404 In this example the total amount of available memory is 1031004 KB. 184864 KB are used by programs and 846140 KB are available for more programs. Don't get confused with the first line that shows that 296348 KB are free! If you look at the usage figures you can see that most of the increase of memory is for buffers and cache. Linux tries to use all the memory for disk buffers and cache. It helps the system to run faster because disk information is already in memory and Linux doesn't have to read it from disk again. If space is needed by a program or application like Oracle, Linux will make the space available immediately. So if your system runs for a while, you will usually see a small number for "free" in the first line, and there is nothing to be worried about. Note: If you create a large SGA (shared memory) and start the database, free won't show all the memory that has been allocated for SGA as "used" right away. That's because Linux does not assign page frames to a memory mapping right after it has been created due to reasons of efficiency. Checking Swap Space Size and Usage You can check the size and current usage of swap space by running the following command: cat /proc/swaps If your swap partition is not large enough, you can add another swap partitions to your system. See "Adding Swap Space" for more information. Adding a permanent swap file to the system is not recommended due to the performance impact of the filesystem layer. Setting Shared Memory Shared memory allows processes to access common structures and data by placing them in shared memory segments. It's the fastest form of IPC (Interprocess Communication) available since no kernel involvement occurs when data is passed between the processes. In fact, data does not need to be copied between the processes. Oracle uses shared memory segments for the SGA (Shared Global Area) which is an area of memory that is shared by all Oracle background and foreground processes. The size of the SGA has a major impact to Oracle's performance since it holds database buffer cache and much more. To see all shared memory settings, run: ipcs -lm Setting SHMMAX Parameter This parameter defines the maximum size in bytes for a shared memory segment. Since the SGA is comprised of shared memory, SHMMAX can potentially limit the size of the SGA. Ideally, SHMMAX should be large enough so that SGA can fit into one segment. The default size on RH 2.1 AS is 33554432. With this value, the Oracle Database Configuration Assistant failed on my server with the following error message: ORA-27123: unable to attach to shared memory segment Setting SHMMAX to 1 GB always worked for me when I setup a medium sized database. However, it is suggested that it should be set to 2 GB; the default maximum size of the SGA is 1.7 GB which requires a larger SHMMAX. And if the available size of the SGA is set to 2.7 GB by changing "mapped base" at the Linux OS level, then SHMMAX should be set to 3 GB. The maximum value of SHMMAX can be set to 4GB-1. (A typical 32-bit Linux system without Physical Address Extension (PAE) is divided into 3 GB user space and 1 GB kernel space.) The default shared memory limit for SHMMAX can be changed in the proc file system without reboot: su - root echo "2147483648" > /proc/sys/kernel/shmmax Alternatively, you can use sysctl(8) to change it: sysctl -w kernel.shmmax=2147483648 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.shmmax=2147483648" >> /etc/sysctl.conf Setting SHMMNI Parameter This parameter sets the maximum number of shared memory segments system wide. The default number on RH 2.1 AS is 4096. To my knowledge this value should be sufficient. # cat /proc/sys/kernel/shmmni 4096 Setting SHMALL Parameter This parameter sets the total amount of shared memory in pages that can be used at one time on the system. So shmall should always be at least ceil(SHMMAX/PAGE_SIZE). The default size for shmall on RH 2.1 AS is 2097152. This should be sufficient since it means that the total amount of shared memory available on the system is 2097152*4096 bytes (shmall*PAGE_SIZE). On i386 architectures, the PAGE_SIZE in RHAS 2.1 (UP and SMP kernel) is 4096 bytes unless you use bigpages which supports the configuration of larger memory pages. # cat /proc/sys/kernel/shmall 2097152 If you don't know what PAGE_SIZE is on your Linux system, copy/paste the following commands into a shell: cat << EOF | #include main() { printf ("%d bytes\n",getpagesize()); } EOF gcc -xc - -o /tmp/getpagesize /tmp/getpagesize; rm -f /tmp/getpagesize This program will display the size of PAGE_SIZE in bytes. Setting Semaphores Semaphores can best be described as counters which are used to provide synchronization between processes or between threads within a process for shared resources like shared memories. System V semaphores support semaphore sets where each one is a counting semaphore. So when an application requests semaphores, the kernel releases them in "sets". The number of semaphores per set can be defined through the kernel parameter SEMMSL. To see all semaphore settings, run: ipcs -ls The SEMMSL Parameter This parameter defines the maximum number of semaphores per semaphore set. Oracle recommends to set SEMMSL to the largest PROCESSES init.ora parameter of any database on the Linux system plus 10. Oracle also recommends to set SEMMSL to a minimum value of 100. The init.ora parameter PROCESSES specifies the maximum number of operating system processes that can be started by the Oracle instance. In a non MTS environment, Oracle spawns a system user process for each connection. This means that in such an environment the PROCESSES parameter defines the maximum number of simultaneous Oracle connections minus sum of all Oracle background processes. It can also be said that the PROCESSES value should never be greater than SEMMSL. The SEMMNI Parameter This parameter defines the maximum number of semaphore sets in the entire Linux system. Oracle recommends to set SEMMNI to a minimum value of 100. The SEMMNS Parameter This parameter defines the total number of semaphores (not semaphore set) in the entire Linux system. A semaphore set can have more than one semaphore, and according to the semget(2) man page, values greater than SEMMSL * SEMMNI makes it irrelevant. Setting it to a minimum value of 256 is for initial Oracle installation only. Oracle recommends to set SEMMNS to the sum of the PROCESSES parameter for each database on the system, adding the largest PROCESSES twice, and then adding 10 for each DB. The maximum number of semaphores that can be allocated on a Linux system will be the lesser of: SEMMNS or (SEMMSL * SEMMNI) Setting SEMMSL and SEMMNI to 100 makes sure that SEMMNS semaphores can be allocated as determined by the above calculation. The SEMOPM Parameter This parameter defines the maximum number of semaphore operations that can be performed per semop(2) system call. The semop(2) function provides the ability to do operations for multiple semaphores with one semop(2) system call. Since a semaphore set can have the maximum number of SEMMSL semaphores per semaphore set, it is often recommended to set SEMOPM equal to SEMMSL. Oracle recommends to set SEMOPM to a minimum value of 100. Setting the Semaphore Kernel Parameters To determine the values of the four described semaphore parameters, run: # cat /proc/sys/kernel/sem 250 32000 32 128 Alternatively, you can run: ipcs -ls All four described semaphore parameters can be changed in the proc file system without reboot: su - root # echo SEMMSL_value SEMMNS_value SEMOPM_value SEMMNI_value > /proc/sys/kernel/sem # These are the values I'm using since I don't want to lower Red Hat's default # values. The only value I raise is SEMOPM to comply with Oracle's minimum # requirement for SEMOPM. echo 250 32000 100 128 > /proc/sys/kernel/sem Alternatively, you can use sysctl(8) to change it: sysctl -w kernel.sem="250 32000 100 128" 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 "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf To see the new updated semaphore settings, run: ipcs -ls Setting File Handles The maximum number of file handles denotes the maximum number of open files that you can have on the Linux system. Setting System Wide Limit for File Handles The value in /proc/sys/fs/file-max sets the maximum number of file handles or open files that the Linux kernel will allocate. When you get error messages about running out of file handles, then you might want to raise this limit. The default value on RH 2.1AS is 8192. For an Oracle server it is recommended that the file handles for the entire system is set to at least 65536. To determine the maximum number of file handles for the entire system, run: cat /proc/sys/fs/file-max To determine the current usage of file handles, run: $ cat /proc/sys/fs/file-nr 1154 133 8192 The file-nr file displays three parameters: - Total allocated file handles - Currently used file handles - Maximum file handles that can be allocted (see also file-max) The kernel dynamically allocates file handles whenever a file handle is requested by an application, but the kernel does not free these file handles when they are released by the application. The kernel recycles these file handles instead. This means that over time the total number of allocated file handles will increase even though the number of currently used file handles may be low. The maximum number of file handles can be changed in the proc file system without reboot: su - root echo "65536" > /proc/sys/fs/file-max Alternatively, you can use sysctl(8) to change it: sysctl -w fs.file-max=65536 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.file-max=65536" >> /etc/sysctl.conf Setting Shell Limits for the Oracle User Most shells like Bash provide control over various resources like the maximum allowable number of open file descriptors or the maximum number of processes available to a user. To see all shell limits, run: ulimit -a For more information on ulimit for the Bash shell, see man bash and search for ulimit. Important Note: Setting "hard" and "soft" limits in the following examples might not work properly when you login as oracle from an SSH session. It might work if you log in as root and su to oracle. If you have this problem, you should try to set UsePrivilegeSeparation in /etc/ssh/sshd_config to "no" and restart the SSH daemon by executing service sshd restart. The privilege separation does not work properly with PAM on Linux. Make sure to talk to your Unix and/or security people before disabling the SSH security feature "Privilege Separation". Setting Limits for the Maximum Number of Open File Descriptors for the Oracle User After you changed and increased /proc/sys/fs/file-max at Setting File Handles, there is still a per user limit of open file descriptors which is set to 1024 by default: $ su - oracle $ ulimit -n 1024 $ To change this, you have to edit the file /etc/security/limits.conf as root and make the following changes or add the following lines, respectively: oracle oracle soft hard nofile nofile 4096 63536 The "soft limit" in the first line defines the number of file handles or open files that the Oracle user will have after login. If the Oracle user gets error messages about running out of file handles, then the Oracle user can increase the number of file handles like in this example up to 63536 ("hard limit") by running the following command: ulimit -n 63536 You can set the "soft" and "hard" limits higher if necessary. Note that I do not recommend to set the "hard" limit for nofile for the oracle user equal to /proc/sys/fs/file-max. If you do that and the oracle user uses up all the file handles, then the whole system will be out of file handles. This could mean that you won't be able to initiate new remote logins any more since the system won't be able to open any PAM modules which are required for performing a login. That's why I set the hard limit to 63536 and not to 65536. You also need to ensure that pam_limits is configured in the file /etc/pam.d/systemauth, or in /etc/pam.d/sshd (for SSH), /etc/pam.d/su (for su), or /etc/pam.d/login (local logins and telnet) if you don't want to enable it for all logins, or if /etc/pam.d/system-auth does not exist like on SUSE. This is the PAM module that will read the /etc/security/limits.conf file. The entry should read like: session /lib/security/pam_limits.so Here are the two "session" entries I have in my /etc/pam.d/system-auth session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so required file: Now login to the oracle account again since the changes will become effective for new login sessions only. $ su - oracle $ ulimit -n 4096 $ Note that the ulimit options are different for other shells. The default limit for oracle is now 4096 and the oracle user can increase the number of file handles up to 63536: $ su - oracle $ ulimit -n 4096 $ ulimit -n 63536 $ ulimit -n 63536 $ To make this change permanent, add "ulimit -n 63536" (for Bash) to the ~oracle/.bash_profile file which is the user startup file for the Bash shell on Red Hat Linux (to verify your shell run: echo $SHELL). To do this you could simply copy/paste the following commands for the oracle's Bash shell: su - oracle cat >> ~oracle/.bash_profile << EOF ulimit -n 63536 EOF Setting Limits for the Maximum Number of Processes for the Oracle User After reading the procedure at Setting Limits for the Maximum Number of Open File Descriptors for the Oracle User, you should now understand what "soft" and "hard" limits are, how to configure pam_limits.so, and how to change the limits. To see the current limit of the maximum number of processes for the oracle user, run: su - oracle ulimit -u Note that the ulimit options are different for other shells. To change the "soft" and "hard" limits for the maximum number of processes for the oracle user, add the following lines to the /etc/security/limits.conf file: oracle oracle soft hard nproc nproc 2047 16384 To make this change permanent, add "ulimit -u 16384" (for Bash) to the ~oracle/.bash_profile file which is the user startup file for the Bash shell on Red Hat Linux (to verify your shell run: echo $SHELL). To do this you could simply copy/paste the following commands for the oracle's Bash shell: su - oracle cat >> ~oracle/.bash_profile << EOF ulimit -u 16384 EOF 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 32bit 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 nonroot 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 0x400000000x50000000 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//maps where stands for the Oracle process ID. The default mapping of an Oracle process might look like this: 08048000-0ab11000 r-xp 00000000 08:09 /ora/product/9.2.0/bin/oracle 0ab11000-0ab99000 rw-p 02ac8000 08:09 /ora/product/9.2.0/bin/oracle 0ab99000-0ad39000 rwxp 00000000 00:00 40000000-40016000 r-xp 00000000 08:01 40016000-40017000 rw-p 00015000 08:01 40017000-40018000 rw-p 00000000 00:00 40018000-40019000 r-xp 00000000 08:09 /ora/product/9.2.0/lib/libodmd9.so 40019000-4001a000 rw-p 00000000 08:09 /ora/product/9.2.0/lib/libodmd9.so 4001a000-4001c000 r-xp 00000000 08:09 /ora/product/9.2.0/lib/libskgxp9.so ... 42606000-42607000 rw-p 00009000 08:01 2.2.4.so 50000000-50400000 rw-s 00000000 00:04 (deleted) 51000000-53000000 rw-s 00000000 00:04 (deleted) 53000000-55000000 rw-s 00000000 00:04 (deleted) ... bfffb000-c0000000 rwxp ffffc000 00:00 273078 273078 0 16 16 0 17935 17935 16066 50 163842 196611 229380 0 /lib/libnss_files/SYSV00000000 /SYSV00000000 /SYSV00000000 /lib/ld-2.2.4.so /lib/ld-2.2.4.so 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 50000000-50400000 rw-s 00000000 00:04 163842 (deleted) /lib/ld-2.2.4.so /SYSV00000000 The base address for SGA (System V shared memory) is 0x50000000: 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//mapped_base needs to be changed where 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//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 OCFS 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: 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 oracle 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. Using bipages also increases TLB (Translation Lookaside Buffers) cache hits which makes the CPUs to run more efficiently in particular with large memory configurations. 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 4 GB SGA 2100 MB bigpages 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=idescsi 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 Oracle Errors and Problems The intention of this section is to describe errors and problems that can occur in connection with the changes covered in this article. For errors regarding the installation of Oracle software and regarding the creation of a database, see Oracle Installation Errors. ORA-3133 errors and attach errors Cause(s): - Running an Oracle binary that has a lower SGA base, but /proc/proc//maps has not been adjusted as well. - SHMMAX value has not been increased large enough. SQL> startup ORA-03113: end-of-file on communication channel SQL> Cause(s): - A too large SGA has been configured - SHMMAX value has not been increased large enough. - Oracle has been relinked with a lower SGA base address but "mapped base" has not been lowered for the shell at the Linux OS level. SQL> startup ORA-27102: out of memory Linux Error: 12: Cannot allocate memory Additional information: 1 Additional information: 262148 SQL> Cause(s): - This error message comes up if the SGA size if too large. ORA-01041: internal error. hostdef extension doesn't exist Cause(s): - If this error comes up and the database is not up, then remove all shared memory segments from the Linux OS. Useful Linux Performance Utilities top Utility This utility shows CPU consumption, memory consumption, and "top" sessions on the Linux server: top Load Averages: The first line of the top output shows you a series of three "load average" numbers. These numbers describe the load on the system. The load average is the average number of processes that are waiting in the queue for CPU time (including processes that are waiting for I/O) for the past 1, 5 and 15 minutes. For example, if a process is sleeping in an uninterruptible state, it will count as a load of 1. Or if you run 3 non-interactive processes that are not waiting for input, then you can expect the average load to be 3. To illustrate that, run the following command in 3 different shells on a server that is not being used: while [ 1 ]; do str="x"; done This loop will use up all the CPU time that it can get. Now wait for about 2-3 minutes and you will see that the average load for the last 1 minute will increase to be 3 and higher. It will be a little bit higher than 3 since there are other processes running on the system. In general, a number less than 1 is ideal. A load average value of 3 is high. And a value of 10 is definitely a heavily loaded system where you can expect delays. You can also use the tload command to display real-time text mode graph on the "load average". CPU States: It shows the load on each processor - the percentage of CPU time in user mode, system mode, niced tasks, and idle. The "user" percentage shows how much processing time the CPU is spending on user processes, and the "system" percentage shows how much processing time the CPU is spending in the system (kernel). Niced tasks are only those processes whose nice value is negative. And note that the processing time for niced processes will also be counted in system and user time, so the total will be more than 100%. However, the best indicators of a stressed CPU is the load average which I described above. Sessions: This section shows the top sessions (Linux processes) in terms of CPU utilization. sar Utility "sar" stands for System Activity Reporter. CPU Usage: To check CPU usage over time, run: sar -u This command is useful if you want to see overall CPU consumption over time. %user shows the percentage of CPU utilization at the user level (application). %system shows the percentage of CPU utilization at the system level (kernel). To check CPU usage 10 times with a time interval of 3 seconds, run: sar -u 3 10 Swap Activity: To check swap activity over time, run: sar -W This command is useful if you suspect memory shortages. pswpin/s shows the total number of swap pages the system brought in per second. pswpout/s shows the total number of swap pages the system brought out per second. These numbers should be low. If not, you need more RAM. To check swap activity 10 times with a time interval of 3 seconds, run: sar -W 3 10 I/O Activity: To check physical disk I/O activity over time, run: sar -b This command is useful if you suspect that the database is I/O bound. See manual pages for more information. To check I/O activity 10 times with a time interval of 3 seconds, run: sar -b 3 10 vmstat Utility This utility provides a report that covers process activity, paging, memory usage, disk I/O, and CPU usage. To create 5 reports with a time interval of 3 seconds, run: $ vmstat 3 5 procs w swpd free 7416 7416 7288 7288 7288 buff 9424 9432 9440 9440 9440 memory cache 45272 45272 45272 45272 45272 si 1 0 0 0 0 swap so 4 0 0 0 0 bi 25 0 0 0 0 io bo 35 17 73 5 8 system in 126 103 104 102 102 cs 33 18 23 12 14 us 3 0 4 0 0 cpu r b sy id 0 0 0 96 0 0 0 100 0 0 1 95 0 0 0 100 0 0 0 100 0 186460 0 186460 0 186460 1 186460 0 186460 See man pages for more information. Oracle Linux Management Determining Which Semaphore Sets and Shared Memory Segments Belong to Each Oracle Database or Instance For an easy way to find and remove Oracle IPC resources for a specific instance, see Finding and Removing Oracle IPC Resources Easily. When Oracle hangs or crashed or when Oracle was killed, then sometimes you will see that shared memory segments and/or semaphore sets have not been released or removed by the Oracle background processes. It is important to make sure that the semaphore sets and shared memory segments are released at the Linux OS level before the database or instance is restarted. Running ipcs will only show you which semaphore sets and which memory segments are owned by the Oracle user account. If you have only one database runnning on your server, then you can simply use the IDs of all shared memory segments and semaphore sets that belong to the Oracle user account and release them via ipcrm: $ su - oracle $ ipcs ------ Shared Memory Segments -------key shmid owner perms bytes nattch status 0x00000000 0 root 600 196608 2 0x00000001 32769 root 600 655360 2 0x00000000 458755 oracle 660 4194304 0 0x00000000 491524 oracle 660 33554432 0 0x00000000 524293 oracle 660 33554432 0 0x00000000 557062 oracle 660 33554432 0 0x00000000 589831 oracle 660 33554432 0 0x00000000 622600 oracle 660 33554432 0 0x00000000 655369 oracle 660 33554432 0 0x00000000 688138 oracle 660 33554432 0 0x3ecee0b0 720907 oracle 660 4194304 0 ------ Semaphore Arrays -------key semid owner perms nsems status ------ Message Queues -------key msqid owner perms used-bytes messages $ To release all shared memory segments that are owned by the Oracle user as listed above, run: $ ipcrm shm 458755 491524 524293 557062 589831 622600 655369 688138 720907 The command for releasing semaphore sets is: $ ipcrm sem ... But if you have more than one database or instance running on the Linux servers, then ipcs will NOT show you the semaphore sets and shared memory segments that are owned by each database or instance. The following steps can be used to find the right IDs for each database or instance: $ su - oracle $ sqlplus /nolog SQL> oradebug setmypid Statement processed. SQL> oradebug ipc Information written to trace file. SQL> select value from v$parameter where name = 'user_dump_dest'; VALUE ------------------------------------------------------------------------------/opt/oracle/admin/test/udump SQL> On my test server, the oradebug ipc command created a file called test_ora_6626.trc in the USER_DUMP_DEST directory /opt/oracle/admin/test/udump. The name of the created trace file is $ORACLE_SID_ora_.trc where stands for the process ID of the Oracle foreground process in a non-MTS environment that's talking to sqlplus here. If you are not sure about the name of the file that was created, run ls -lrt to see the timestamp of the latest trace file created in the USER_DUMP_DEST directory. When you open the trace file (in my example test_ora_6626.trc), you can find the semaphore ID for this database after the line "Semaphore List=". Here are the semaphore sets on my test box for the Oracle database: /opt/oracle/admin/test/udump/test_ora_6626.trc: [SKIP] Maximum processes: = 150 Number of semaphores per set: = 154 Semaphores key overhead per set: = 4 User Semaphores per set: = 150 Number of semaphore sets: = 1 Semaphore identifiers: = 1 Semaphore List= 98304 -------------- system semaphore information ------------------ Shared Memory Segments -------[SKIP] To release all semaphore sets that are owned by the database as listed above, run: $ ipcrm sem 98304 And here are the shared memory IDs on my test box for the Oracle database: /opt/oracle/admin/test/udump/test_ora_6626.trc: [SKIP] Area #0 `Fixed Size' containing Subareas 0-0 Total size 000000000006e078 Minimum Subarea size 00000000 Area Subarea Shmid Stable Addr Actual Addr 0 0 1671186 0x00000050000000 0x00000050000000 Subarea size Segment size 000000000006f000 0000000000400000 Area #1 `Variable Size' containing Subareas 1-7 Total size 000000000e000000 Minimum Subarea size 01000000 Area Subarea Shmid Stable Addr Actual Addr 1703955 0x00000051000000 0x00000051000000 Subarea size Segment size 0000000002000000 0000000002000000 Area Subarea Shmid Stable Addr Actual Addr 1 2 1736724 0x00000053000000 0x00000053000000 Subarea size Segment size 0000000002000000 0000000002000000 Area Subarea Shmid Stable Addr Actual Addr 1 3 1769493 0x00000055000000 0x00000055000000 Subarea size Segment size 0000000002000000 0000000002000000 Area Subarea Shmid Stable Addr Actual Addr 1 4 1802262 0x00000057000000 0x00000057000000 Subarea size Segment size 0000000002000000 0000000002000000 Area Subarea Shmid Stable Addr Actual Addr 1 5 1835031 0x00000059000000 0x00000059000000 Subarea size Segment size 0000000002000000 0000000002000000 Area Subarea Shmid Stable Addr Actual Addr 1 6 1867800 0x0000005b000000 0x0000005b000000 Subarea size Segment size 0000000002000000 0000000002000000 Area Subarea Shmid Stable Addr Actual Addr 1 7 1900569 0x0000005d000000 0x0000005d000000 Subarea size Segment size 0000000002000000 0000000002000000 Area #2 `Redo Buffers' containing Subareas 8-8 Total size 00000000000a3000 Minimum Subarea size 00000000 Area Subarea Shmid Stable Addr Actual Addr 2 8 1933338 0x0000005f000000 0x0000005f000000 Subarea size Segment size 00000000000a3000 0000000000400000 Area #3 `skgm overhead' containing Subareas 9-9 Total size 0000000000001000 Minimum Subarea size 00000000 Area Subarea Shmid Stable Addr Actual Addr 3 9 1933338 0x0000005f0a3000 0x0000005f0a3000 Subarea size Segment size 0000000000001000 0000000000400000 [SKIP] 1 1 To release all shared memory segments that are owned by the database as listed above, run: $ ipcrm shm 1671186 1703955 1736724 1769493 1802262 1835031 1867800 1900569 1933338 To verify if the shared memory segments and semaphore sets have been released, run: $ ipcs Finding and Removing Oracle IPC Resources Easily If you need to remove Oracle's IPC resources after e.g. an instance crash, you can use Oracle's sysresv command. Here are a few self explanatory examples that show how sysresv works: SID is up and running: oracle$ sysresv -i IPC Resources for ORACLE_SID "test" : Shared Memory: ID KEY 2818058 0xdc70f4e4 Semaphores: ID KEY 688128 0xb11a5934 720897 0xb11a5935 753666 0xb11a5936 Oracle Instance alive for sid "test" SYSRESV-005: Warning Instance maybe alive - aborting remove for sid "test" oracle$ SID has crashed and resources were not released: oracle$ sysresv -i IPC Resources for ORACLE_SID "test" : Shared Memory: ID KEY 524302 0xdc70f4e4 Semaphores: ID KEY 98304 0xb11a5934 131073 0xb11a5935 163842 0xb11a5936 Oracle Instance not alive for sid "test" Remove ipc resources for sid "test" (y/n)?y Done removing ipc resources for sid "test" oracle$ Checking Oracle's IPC resources: oracle$ sysresv IPC Resources for ORACLE_SID "test" : Shared Memory ID KEY No shared memory segments used Semaphores: ID KEY No semaphore resources used Oracle Instance not alive for sid "test" oracle$ Hardware Recommendation It really depends on what kind of database you want to setup and run, how large the database is etc. But people keep asking me what I would recommend. If you want to get a feeling how well Oracle9i (non-RAC system) runs on Linux/Intel systems, and if you don't want to spend "too much money", here is what I would buy: - 2-way server, 2.4GHz Xeon - 4 GB RAM; RAM is cheap and gives you usually the biggest "bang for the buck". - Large Internal Ultra SCSI disks with a hardware RAID controller card References Oracle's Linux Center An Overview of Red Hat Advanced Server V2.1 Reliability, Availability, Scalability, and Manageability (RASM) Features Linux Virtual Memory in Red Hat Advanced Server 2.1 and Oracle's Memory Usage Characteristics Tips and Techniques: Install and Configure Oracle9i on Red Hat Linux Advanced Server Oracle9iR2 on Linux: Performance, Reliability and Manageability Enhancements on Red Hat Linux Advanced Server 2.1 Delivering Leading TPC-C Figures with Red Hat Linux Advanced Server (Red Hat Webcast Tuesday, 22nd October, 2002) Understanding the Linux Kernel, 2nd edition