Oracle® Database

3.1 Install libaio Before Installing or Upgrading

Before upgrading to or installing Oracle Database 10g release 2, install the libaio package.

3.2 Install oracleasm-support to use ASMLib

Install oracleasm-support package version 2.0.0.1 or higher to use ASMLib on Red Hat Enterprise Linux 4.0 Advanced Server or SUSE Linux Enterprise Server 9. At the time of this publication, the ASMLib user space tools and kernel module packages are not yet available for SUSE Linux Enterprise Server 10.

3.3 Red Hat Enterprise Linux 4.0

Before installing Oracle Database 10g release 2 on Red Hat Enterprise Linux 4.0 Update 1, install the following packge:

binutils-2.15.92.0.2-13.0.0.0.2.x86_64

This package can be downloaded from the following link:

http://oss.oracle.com/projects/compat-oracle/dist/files/RedHat/binutils-2.15.92.0.2-13.0.0.0.2.x86_64.rpm

This issue is tracked with Oracle bug 4619031.

3.4 Oracle Lite

Before installing Oracle Lite, ensure that the following package is installed:

libxml2-2.5.10-7.i386.rpm

3.5 Configuring Kernel Parameters

After updating the values of kernel parameters in the /etc/sysctl.conf file, ensure that you either reboot the computer or run the sysctl -p command to make the changes of the /etc/sysctl.conf file available in the active kernel memory.

On SUSE Linux Enterprise Server 9.0, ensure that you set the following kernel parameter:

disable_cap_mlock = 1

On SUSE Linux Enterprise Server 10, ensure that you set the hugetlb_shm_group kernel parameter to the gid of the group used as the dba group. For example, on a system using a group named dba with the following entry in the /etc/group file:

dba:!:104:oracle

On SUSE Linux Enterprise Server 10, ensure that you set the hugetlb_shm_group kernel parameter to the GID of the group used as the dba group. For example, on a system using a group named dba with the dba:!:104:oracle entry in the /etc/group file, the hugetlb_shm_group kernel parameter should be set to the following value:

hugetlb_shm_group = 104

5.1 Upgrading Oracle Real Application Clusters Release 9.2

If you are upgrading a 9.2 RAC environment to Oracle Database 10g release 2 on Red Hat Linux 3.0, then you must apply a patch to GLIBC before proceeding with the Oracle Clusterware installation. Follow the instructions documented in OracleMetaLink note 284535.1.

This issue is tracked with Oracle bug 3006854.

5.2 Oracle Universal Installer Operating System Prerequisite Check on SUSE Linux Enterprise Server 10

If you are installing Oracle database 10g on SUSE Linux Enterprise Server 10, the current version of the Oracle Universal Installer does not recognized SLES10 as a supported operating system and does not perform the installation.

Workaround #1: Run the Oracle Universal Installer using the ignoreSysPrereqs flag which causes the installer to skip the operating system check and continue with the installation:

./runinstaller -ignoreSysPrereqs

As a side effect, the installer also skips other checks during the installation.

Workaround #2: The installation will pass the operating system prerequisite checks if you change each 10 to 9 in the /etc/SuSE-release file. Ensure that you replace the original values in the /etc/SuSE-release file after the Oracle installation is complete.

This causes the installer to consider the system to be running SUSE Linux Enterprise Server 9 and the operating system check passes. The changes to the /etc/SuSE-release file should be reverted after the installation of all Oracle software is complete as some YaST tools require the original content.

5.3 Installing Oracle Cluster Ready Services on SUSE Linux Enterprise Server 10

Near the end of the installation of Oracle Cluster Ready Services, Oracle Universal Installer prompts for the $CRS_HOME/root.sh script to be run on all of the nodes in the cluster. When the root.sh script is run on the last node in the cluster, the script calls the VIPCA utility, which fails. Refer to the "SRVCTL and VIPCA Utilities Set the LD_ASSUME_KERNEL Parameter" section for more details.

Workaround: Before running the root.sh script on the last node in the cluster, alter the $CRS_HOME/bin/vipca script commenting out lines 119 through 123:

arch='uname -m'
#       if [ "$arch" = "i686" -o "$arch" = "ia64" -o "$arch" = "x86_64" ]
#       then
#            LD_ASSUME_KERNEL=2.4.19
#            export LD_ASSUME_KERNEL
#       fi

With the lines commented out, root.sh should be able to call VIPCA successfully. Ensure that you do not comment out line 118, which sets the arch variable as that is needed by the script.

5.4 Installing Enterprise Security Manager

To install Oracle Security Manager, install Oracle Client and then select the Administrator installation type.

5.5 Upgrading Oracle Clusterware 10.1.x to Oracle Clusterware 10.2

When upgrading from 10.1.x to 10.2, Oracle Clusterware will not start if the host name directory under the /etc/oracle/scls_scr directory includes the domain name. The following error message is displayed when you run the rootupgrade.sh script.

A file or directory in the path name does not exist.
/etc/init.cssd[509]: /etc/oracle/scls_scr/host_name/root/cssrun: 0403-005
Cannot create the specified file.

Workaround: Move the /etc/oracle/scls_scr/hostname.domain_name directory to /etc/oracle/scls_scr/hostname and rerun the rootupgrade.sh script.

This issue is tracked with Oracle bug 4472284.

5.6 extjob Executable Required Directory Permissions

To enable the extjob executable to locate required libraries, the $ORACLE_HOME/lib directory and all of its parent directories must have execute permissions for group and other.

5.7 Modifying a Virtual IP Address Node Application

Use the srvctl modify nodeapps command to modify the name, IP address, or netmask of an existing virtual IP address (VIP) resource. Use the -A argument to include the existing interfaces for the VIP:

srvctl modify nodeapps -n mynode1 -A 100.200.300.40/255.255.255.0/eth0

This issue is tracked with Oracle bug 4500688.

5.8 Raw Devices on Red Hat Enterprise Linux 4.0

When you restart a Red Hat Enterprise Linux 4.0 system, raw devices revert to their original owners and permissions by default. If you are using raw devices with this operating system for your Oracle files, for example, for ASM storage or Oracle Clusterware files, you need to override this default behavior. To do this, add an entry to the /etc/rc.d/rc.local file for each raw device containing the chmod and chown commands required to reset them to the required values.

As an example, here are sample entries in a /etc/rc.d/rc.local file that control the restart behavior of raw devices for two ASM disk files (/dev/raw/raw6 and /dev/raw/raw7), two Oracle Cluster Registry files (/dev/raw/raw1 and /dev/raw/raw2), and three Oracle Clusterware voting disks (/dev/raw/raw3, /dev/raw/raw4, and /dev/raw/raw5):

# ASM
chown oracle:dba /dev/raw/raw6
chown oracle:dba /dev/raw/raw7
chmod 660 /dev/raw/raw6
chmod 660 /dev/raw/raw7
# OCR
chown root:oinstall /dev/raw/raw1
chown root:oinstall /dev/raw/raw2
chmod 660 /dev/raw/raw1
chmod 660 /dev/raw/raw2
# Voting Disks
chown oracle:oinstall /dev/raw/raw3
chown oracle:oinstall /dev/raw/raw4
chown oracle:oinstall /dev/raw/raw5
chmod 644 /dev/raw/raw3
chmod 644 /dev/raw/raw4
chmod 644 /dev/raw/raw5

5.9 Database Migration

Review the following sections if you want to migrate Oracle Database 10g release 2 database from Linux x86 to Linux x86-64:

• Migrating Single Instance Database from Linux x86 to Linux x86-64

• Migrating Oracle RAC Database from Linux x86 to Linux x86-64

6.1 Building Pro*C Applications if PostgreSQL is Installed

If the postgresql-devel package is installed on the system, then you must add the following directory to the beginning of the sys_include parameter in the $ORACLE_HOME/precomp/admin/pcscfg.cfg file before building Pro*C applications:

$ORACLE_HOME/precomp/public

If you do not make this change, then you may encounter errors similar to the following when linking the applications:

/tmp/ccbXd7v6.o(.text+0xc0): In function `drop_tables': 
: undefined reference to `sqlca'

This issue is tracked with Oracle bug 3933309.

6.2 Encoding Information Not Present in Translated Help Files

If the system uses a European language, you might see corrupted characters in Table of Contents of database tools, such as Database Configuration Assistant.

This issue is tracked with Oracle bug 3957096.

Workaround: If the system uses a European language, do not use the .UTF-8 locale. For example, if the system uses German, set the LANG and LC_ALL environment variables to de_DE instead of de_DE.UTF-8.

6.3 Oracle Clusterware Files Issues

The following note applies if you are using Red Hat Enterprise Linux 4.0 or SUSE Linux Enterprise Server 10 and using raw devices to store the Oracle Cluster Registry (OCR) and the voting disk for Oracle Clusterware, or using raw devices for Automatic Storage Management (ASM) database files. For each raw device used for the purposes listed, you must add two entries in the /etc/rc.d/rc.local file on Red Hat Enterprise Linux 4.0 or the /etc/init.d/after.local file on SUSE Linux Enterprise Server 10 after running the root.sh script following the installation of Oracle Clusterware.

For each OCR file, the entries should look as follows, where oinstall is the Oracle install group and /dev/raw/rawn is an individual device file:

chown root:oinstall /dev/raw/rawn
chmod 640 /dev/raw/rawnmar

For each voting disk file, the entries should look as follows, where oracle is the Oracle user, oinstall is the Oracle install group, and /dev/raw/rawn is an individual device file:

chown oracle:oinstall /dev/raw/rawn
chmod 644 /dev/raw/rawnmar

For each ASM file, the entries should look as follows, where oracle is the Oracle user, oinstall is the Oracle install group, and /dev/raw/rawn is an individual device file:

chown oracle:oinstall /dev/raw/rawn
chmod 660 /dev/raw/rawnmar

6.4 Cluster Verification Utility

This section lists the issues with Cluster Verification Utility on Red Hat Enterprise Linux 4.0 and SUSE Linux Enterprise Server 9 and 10:

• Cluster Verification Utility (CVU) does not support shared checks for raw disks used for Oracle Cluster File System version 2 on Red Hat Enterprise Linux 4.0 and SUSE Linux Enterprise Server 9 and 10.

• Cluster Verification Utility (CVU) does not detect SMP-Kernel rpms for the hosts and displays the "Kernel check failed" message. In verbose mode, the status for kernel is dislpayed as "missing".

  This issue is tracked with Oracle bug 4685951.

• The preinstallation stage verification checks for Oracle Clusterware and Oracle Real Applications Clusters and reports missing packages. Ignore the following missing packages and continue with the installation:

  compat-gcc-7.3-2.96.128
  compat-gcc-c++-7.3-2.96.128
  compat-libstdc++-7.3-2.96.128
  compat-libstdc++-devel-7.3-2.96.128
  

6.5 Removing Metrics for Wait Classes Removes Them Permanently

Do not remove the key values for the wait class metrics. Doing so removes them permanently and currently there is no easy way to recover them.

This issue is tracked with Oracle bug 4602952.

6.6 Support for 64-Bit JDBC

For Oracle Database 10g release 2 on Linux x86-64, 64-bit JDBC (using JDK 5) is supported.

6.7 Patch for Oracle Clusterware Configuration with Voting Disk on Network Attached Storage

To resolve Oracle Clusterware configuration issue when voting disk is on Network Attached Storage, you need to apply the patch tracked through Oracle bug 4697432.

6.8 SRVCTL and VIPCA Utilities Set the LD_ASSUME_KERNEL Parameter

The SRVCTL and VIPCA utilities shipped with Oracle Database 10g release 2 and Oracle Clusterware software set the environmental variable LD_ASSUME_KERNEL. On SUSE Linux Enterprise Server 10, because the older Linux threads API has been removed from GLIBC, setting this parameter causes the SRVCTL and VIPCA utilities to exit with the following error:

/opt/oracle/crs/jdk/jre/bin/java: 
error while loading shared libraries: 
libpthread.so.0: cannot open shared object file: 
No such file or directory

Workaround: Comment out the lines that set the LD_ASSUME_KERNEL variable from the VIPCA and SRVCTL utilities. For the VIPCA utility alter the $CRS_HOME/bin/vipca script commenting out lines 119 through 123 as follows:

arch='uname -m'
#       if [ "$arch" = "i686" -o "$arch" = "ia64" -o "$arch" = "x86_64" ]
#       then
#            LD_ASSUME_KERNEL=2.4.19
#            export LD_ASSUME_KERNEL
#       fi

With the lines commented out, root.sh should be able to call VIPCA successfully. Ensure that you do not to comment out line 118 which sets the arch variable as that is needed by the script.

For the SRVCTL utility alter the $CRS_HOME/bin/srvctl and the $ORACLE_HOME/bin/srvctl scripts commenting out lines 173 and 174 as follows:

#Remove this workaround when the bug 3937317 is fixed#LD_ASSUME_KERNEL=2.4.19#export LD_ASSUME_KERNEL

6.9 Mapping of 127.0.0.2 to the Local Hostname

By default, the hostname of a machine is mapped to the IP address 127.0.0.2 through an entry in the /etc/hosts similar to the following on SUSE Linux Enterprise Server 10:

127.0.0.2       test test.example.com

YaST does this to provide compatibility with earlier versions of the applications that had problems running on desktops with dynamically assigned hostnames from DHCP. This mapping may cause certain Oracle networking libraries to encounter errors when they attempt to resolve the hostname of the machine. To avoid these problems, the entry should be removed from the /etc/hosts file. Note that several network related YaST utilities may add this entry back to the file.