Oracle® Database Release Notes 10g Release 2 (10.2) for Linux Itanium Part Number B15673-14 |
|
PDF · Mobi · ePub |
Release Notes
10g Release 2 (10.2) for Linux Itanium
B15673-14
March 2012
This document contains important information that was not included in the platform-specific or product-specific documentation for this release. This document supplements Oracle Database Readme and may be updated after it is released.
To check for updates to this document and to view other Oracle documentation, refer to the Documentation section on the Oracle Technology Network (OTN) Web site:
http://www.oracle.com/technetwork/indexes/documentation/index.html
For additional information about this release, refer to the readme files located in the $ORACLE_HOME/relnotes
directory.
Note:
The Database Quick Installation Guides are no longer available in printed format. These documents are available with the media in the same location as the software and on Oracle Technology Network.This document contains the following topics:
The latest certification information for Oracle Database 10g Release 2 (10.2) is available on My Oracle Support (formerly OracleMetaLink) at:
Pro*COBOL with Micro Focus Server Express 4.0 SP2 is supported on Red Hat Linux 4. However, to work with Pro*COBOL, install the 5037378 patch.
Starting with Oracle Database 10g Release 2 (10.2.0.4), the following operating systems are supported in addition to the list documented in Oracle Database Installation Guide for Linux Itanium:
Red Hat Enterprise Linux 5
SUSE Linux Enterprise Server 10
Refer to "List of Packages for Red Hat Enterprise Linux 5" and "List of Packages for SUSE Linux Enterprise Server 10" sections for the list of packages for Oracle Database 10g Release 2.
Starting with Oracle Database 10g Release 2 (10.2.0.5), SUSE Linux Enterprise Server 11 is supported in addition to the list documented in Oracle Database Installation Guide for Linux Itanium.
Refer to "List of Packages for SUSE Linux Enterprise Server 11" section for the list of packages for Oracle Database 10g Release 2.
Starting with Oracle Database 10g Release 2 (10.2.0.4), Generic Connectivity Using ODBC (64-bit) is supported on Linux Itanium.
Grid Control is not supported with Oracle Database 10g Release 2 (10.2).
Oracle Database 10g Release 2 (10.2) can be managed as a target by Grid Control 10.1.0.4. However, Oracle Database 10g Release 2 is not supported by Grid Control 10.1.0.4 as a repository.
You must review the following sections before installing Oracle Database 10g Release 2:
Before upgrading to or installing Oracle Database 10g Release 2, install the libaio
package.
Install oracleasm-support
package version 2.0.0.1 or higher to use ASMLib on Red Hat Enterprise Linux 4 Advanced Server or SUSE Linux Enterprise Server 9.
After updating the values of kernel parameters in the /etc/sysctl.conf
file, ensure that you either restart 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, 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 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
If you do not use the ignoreSysPrereqs
flag when you install Oracle Database on Red Hat Enterprise Linux 3.x, Red Hat Enterprise Linux 4.x, Red Hat Enterprise Linux 5.x, SUSE Linux Enterprise Server 8.x, SUSE Linux Enterprise Server 9.x, SUSE Linux Enterprise Server 10, or SUSE Linux Enterprise Server 11, then the prerequisite check to validate the kernel version might fail.
Workaround:
Ignore the error message and proceed with the installation if your system has one of the following kernel versions (or later):
Red Hat Enterprise Linux 3.0: 2.4.21-20.EL Red Hat Enterprise Linux 4.0: 2.6.9-11.EL Red Hat Enterprise Linux 5.0: 2.6.18-53.EL SUSE Linux Enterprise Server 8.0: 2.4.21-278 SUSE Linux Enterprise Server 9.0: 2.6.5-139 SUSE Linux Enterprise Server 10: 2.6.16.21 SUSE Linux Enterprise Server 11: 2.6.27.19
This issue is tracked with Oracle bug 11847748.
If you intend to use Oracle HTTP server, which is included in Companion CD of Oracle Database 10g Release 2 (10.2) Media pack, refer to the My Oracle Support( formerly OracleMetalink)note 317085.1 for more information about using Oracle HTTP server on Red Hat Enterprise Linux 4.
If you intend to use Oracle HTTP Server, which is included in Companion CD of Oracle Database 10g Release 2 (10.2) Media pack, refer to the My Oracle Support ( formerly OracleMetalink) note 564174.1 for more information about using Oracle HTTP Server on Red Hat Enterprise Linux 5.
Legacy entry points required by this version of Apache (libdb.so.2
) are moved to gdbm-1.8.0-26.2.1.i386
. You must create a symlink using the following command:
$ ln -s /usr/lib/libgdbm.so.2.0.0 /usr/lib/libdb.so.2
Review the following sections for information about issues that affect Oracle Database installation, configuration, and upgrade:
Oracle Universal Installer Operating System Prerequisite Checks
Upgrading Oracle Clusterware 10.1.x to Oracle Clusterware 10.2
Configuring Storages Devices for Oracle Clusterware on 2.6 Kernel Distributions
Installing Oracle Database Client into an Existing Oracle Home
For late-breaking updates and best practices about preupgrades, postupgrades, compatibility, and interoperability discussions refer to note 466181.1 on My Oracle Support (formerly OracleMetaLink) (https://support.oracle.com
) that links to "10g Upgrade Companion" page.
The default makefile version on Red Hat Enterprise Linux 5 is make 3.81
. In this makefile version, the default database name (db_name
) is not recognized by the Oracle clients, which are directly called from the makefile. This issue is seen even on other platforms when makefile version 3.81 is used.
The workaround is to use makefile version 3.79 or use @db_name
whenever username
/password
is used in the makefile.
In Chapter 4, Section 4.2, "Preparing to Install Oracle Clusterware with OUI," of the Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide for Linux 10g Release 2 (10.2) for Linux, required voting disk permissions are listed as 644. This is incorrect. Voting disk permissions should be set to 640.
If you are upgrading a 9.2 Oracle RAC environment to Oracle Database 10g Release 2 on Red Hat Linux 3, then you must apply a patch to GLIBC
before proceeding with the Oracle Clusterware installation. Follow the instructions documented in My Oracle Support( formerly OracleMetalink) note 284535.1.
This issue is tracked with Oracle bug 3006854.
If you are installing Oracle Database 10g on Red Hat Enterprise Linux 5 or SUSE Linux Enterprise Server 10, the current version of Oracle Universal Installer does not recognized these operating systems as supported operating systems and does not perform the installation.
Workaround #1 (recommended): 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: On Red Hat Enterprise Linux 5, the installation passes the operating system prerequisite checks if you change each Red Hat Enterprise Linux 5 to Red Hat Enterprise Linux 4 in the /etc/redhat-release
file. Ensure that you replace the original values in the /etc/redhat-release
file after the Oracle installation is complete.
Original Value | Changed Value |
---|---|
Red Hat Enterprise Linux server release 5 |
Red Hat Enterprise Linux server release 4 |
On SUSE Linux Enterprise Server 10, the installation passes the operating system prerequisite checks if you change each SUSE Linux Enterprise Server 10 to SUSE Linux Enterprise Server 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.
Original Value | Changed Value |
---|---|
SUSE Linux Enterprise Server 10 (x86_64) |
SUSE Linux Enterprise Server 9 (x86_64) |
VERSION = 10 |
VERSION = 9 |
This workaround causes Oracle Universal Installer to consider the system to be running earlier version of the operating system and the operating system check passes. The changes to the release file should be reverted after the installation of all Oracle software is complete. The changes to the release file could impact the ability of other tools to be properly installed on the operating system.
Near the end of the installation of Oracle Clusterware, 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 on Red Hat Enterprise Linux 5 and SUSE Linux Enterprise Linux 10. 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 root.sh
script.
Before running root.sh
in the first node of a shared Oracle Clusterware home, add the following line in the $ORA_CRS_HOME/opmn/conf/ons.config
file:
usesharedinstall=true
This issue is tracked with Oracle bug 4454562.
To install Oracle Security Manager, install Oracle Database Client and then select the Administrator installation type.
When upgrading from 10.1.x to 10.2, if the host name directory under the /etc/oracle/scls_scr
directory includes the domain name, then the following error message is displayed when you run the rootupgrade.sh
script and the Oracle Clusterware stack does not start:
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.
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
.
When modifying the name, IP address, or netmask of an existing virtual IP address (VIP) resource, use the following command:
srvctl modify nodeapps
and include the existing interfaces for the VIP in the -A
argument. For example:
srvctl modify nodeapps -n mynode1 -A 100.200.300.40/255.255.255.0/eth0
This issue is tracked with Oracle bug 4500688.
When you restart a Red Hat Enterprise Linux 4, or Red Hat Enterprise Linux 5 system, raw devices revert to their original owners and permissions by default. If you are using raw devices with this operating system for the Oracle files, for example, for ASM storage or Oracle Clusterware files, you must 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
If different user IDs are used for installing Oracle Database 10g and Oracle Clusterware, then restarting the system results in OCR errors. Refer to the My Oracle Support( formerly OracleMetalink) note 551478.1 for more information.
Workaround: Oracle recommends that you apply patch set 10.2.0.3 or higher to Oracle Clusterware installation before patching Oracle Database.
This issue is tracked with the Oracle bug 4748946.
This section is for database and system administrators who intend to install or migrate to Oracle 10g Release 2 (10.2.0) Oracle RAC on Red Hat Enterprise Linux 5 and who must configure raw devices for Oracle RAC and Oracle Clusterware. The Linux 2.6 kernel with these distributions requires additional configuration steps. The section contains the following topics:
With the Linux 2.6 kernel, support for raw devices is deprecated. The preferred way to access block devices is direct input/output to the devices using O_DIRECT
. Therefore, /etc/sysconfig/rawdevices
file of Red Hat Enterprise Linux 4 and Oracle Linux 4, and /etc/udev/rules.d/60-raw.rules
file of Red Hat Enterprise Linux 5 and Oracle Linux 5 are deprecated. For details, refer to the Linux documentation for your 2.6 kernel.
The 2.4 kernel device file naming scheme devlabel
maintained persistent device file names between server restarts. By default, the 2.6 kernel device file naming scheme udev
dynamically creates device file names when the server is started, and assigns ownership of them to root
. If udev
applies default settings, then it changes device file names and owners for voting disks or Oracle Cluster Registry partitions, corrupting them when the server is restarted. For example, a voting disk on a device named /dev/sdd
owned by the user crs
may be on a device named /dev/sdf
owned by root
after restarting the server.
To prevent corruption, you must create a custom rules file. When udev
is started, it sequentially carries out rules (configuration directives) defined in rule files. These files are in the path /etc/udev/rules.d/
. Rules files are read in lexical order. For example, rules in file 10-wacom.rules
are parsed and carried out before rules in rule file 90-ib.rules
. Where rules files describe the same devices, on Asianux and Red Hat, the last file read is the one that is applied. (On SUSE 2.6 kernels, it is the first file read).
This section contains the following topics:
Configure SCSI_ID to Return Unique Device Identifiers
Before you can configure udev
to name devices, you must first configure scsi_id
to return device identifiers, and then ensure that these devices are visible and accessible on all cluster nodes. To do this, complete the following task:
Modify the /etc/scsi_id.config
file by adding or replacing the 'option=-b' parameter/value pair (if it exists) with 'option=-g'. For example:
# cd /etc # cp scsi_id.config scsi_id.config.orig # grep -v ^# /etc/scsi_id.config vendor="ATA",options=-p 0x80 options=-g
Run the command fdisk
(/sbin/fdisk
) to ensure that Clusterware devices are visible. For example:
# /sbin/fdisk -l /dev/sdb1 /dev/sde1 Disk /dev/sdb1: 261 MB, 261890048 bytes 9 heads, 56 sectors/track, 1014 cylinders Units = cylinders of 504 * 512 = 258048 bytes Disk /dev/sdb1 does not contain a valid partition table Disk /dev/sde1: 52 MB, 52403200 bytes 2 heads, 50 sectors/track, 1023 cylinders Units = cylinders of 100 * 512 = 51200 bytes Disk /dev/sde1 does not contain a valid partition table
In some cases, to see newly provisioned or modified) devices on shared storage, you may need to update cluster node operating systems. Do this either by restarting the nodes, or by using commands such as /sbin/partprobe
device
, or sfdisk -r
device
. Resolve any issues preventing cluster nodes from correctly seeing or accessing storage devices you intend to use for Clusterware files before proceeding.
Note:
At this point, cluster nodes may refer to the devices using different device file names. This is expected.Run the command scsi_id
(/sbin/scsi_id
) on storage devices from one cluster node to obtain their unique device identifiers. When running the scsi_id
command with the -s
argument, the device path and name passed should be that relative to the sysfs
directory /sys
(for example, /block/
device
) when referring to /sys/block/
device. For example:
# /sbin/scsi_id -g -s /block/sdb/sdb1 360a98000686f6959684a453333524174 # /sbin/scsi_id -g -s /block/sde/sde1 360a98000686f6959684a453333524179
Record the unique SCSI identifiers of Clusterware devices, so you can provide them when required in the following section, "Configure Udev for Persistent Naming of Oracle Clusterware Devices".
Note:
The commandscsi_id
should return the same device identifier value for a given device, regardless of which node the command is run from.Configure Udev for Persistent Naming of Oracle Clusterware Devices
Configure persistent user-defined naming of Oracle Clusterware device file names in a udev rules file. This step is optional, but recommended.
The default rule files affecting storage devices are rule files 50 and 51. So, create a custom rules file using the format [number]-[name][.rules] with a number value greater than 51 to ensure that the device settings you provide are the ones applied. For example:
55-oracle-naming.rules
To do this, complete the following tasks:
Create a custom udev
device naming rule file. For example:
# touch /etc/udev/rules.d/55-oracle-naming.rules
Use a text editor such as vi
, add to the custom device naming rule file the device-matching rules for the storage devices you intend to use with Oracle Clusterware, matching them to the unique SCSI identifiers you determined in the preceding section. For example:
# Configure persistent, user-defined Oracle Clusterware device file names KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="360a98000686f6959684a453333524174", NAME="ocr1", OWNER="root", GROUP="oinstall", MODE="0640" KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="360a98000686f6959684a453333524179", NAME="vote1", OWNER="oracle", GROUP="oinstall", MODE="0640"
For each rule, if all specified keys (KERNEL, BUS, PROGRAM, RESULT) are matched, then the rule is applied and the specified assignments (NAME, OWNER, GROUP, MODE) are assigned to the device file name. However, if one or more keys are unmatched, then the rule is completely ignored and the default (arbitrary) kernel-assigned device file names are assigned to devices.
Note:
Note the following points when using udev for device persistent naming:Double equals "==" denote conditionals, while the single equal "=" denotes assignments. However, in Oracle Linux 4 and Red Hat Enterprise Linux 4 there are only single equals playing both the roles.
Using the NAME keyword replaces the standard /dev/sdb1 name with your own after a restart.
If you want to preserve the standard name /dev/sdb1, use the SYMLINK+= keyword instead of the NAME keyword. This creates a standard Linux symlink and keep the original device name. Programs such as Clusterware, should use the symlink chosen name and not the physical device, which may change after each restart. However, the symlink always points to the correct device.
Note:
In the example rules files shown, Oracle Clusterware devices are created with oraInventory group (oinstall
). Oracle recommends that you create these devices since this is the right starting point for device permissions, later during the installation they are changed by root.sh
. Setting these incorrectly does not prevent a user from running Cluster Verification Utility, it (CVU) prints warnings.Run the command udevtest
(/sbin/udevtest
) to test the udev
rules configuration you have created. The output should indicate that the block devices are available and the rules are applied as expected. For example:
# udevtest /block/sdb/sdb1 main: looking at device '/block/sdb/sdb1' from subsystem 'block' udev_rules_get_name: add symlink 'disk/by-id/scsi-360a98000686f6959684a453333524174-part1' udev_rules_get_name: add symlink 'disk/by-path/ip-192.168.1.1:3260-iscsi-iqn.1992-08.com.netapp:sn.887085-part1' udev_node_mknod: preserve file '/dev/.tmp-8-17', because it has correct dev_t run_program: '/lib/udev/vol_id --export /dev/.tmp-8-17' run_program: '/lib/udev/vol_id' returned with status 4 run_program: '/sbin/scsi_id' run_program: '/sbin/scsi_id' (stdout) '360a98000686f6959684a453333524174' run_program: '/sbin/scsi_id' returned with status 0 udev_rules_get_name: rule applied, 'sdb1' becomes 'ocr1' udev_device_event: device '/block/sdb/sdb1' validate currently present symlinks udev_node_add: creating device node '/dev/ocr1', major = '8', minor = '17', mode = '0640', uid = '0', gid = '500' udev_node_add: creating symlink '/dev/disk/by-id/scsi-360a98000686f6959684a453333524174-part1' to '../../ocr1' udev_node_add: creating symlink '/dev/disk/by-path/ip-192.168.1.1:3260-iscsi-iqn.1992-08.com.netapp:sn.84187085 -part1' to '../../ocr1' main: run: 'socket:/org/kernel/udev/monitor' main: run: '/lib/udev/udev_run_devd' main: run: 'socket:/org/freedesktop/hal/udev_event' main: run: '/sbin/pam_console_apply /dev/ocr1 /dev/disk/by-id/scsi-360a98000686f6959684a453333524174-part1 /dev/disk/by-path/ip-192.168.1.1:3260-iscsi-iqn.1992-08.com.netapp:sn.84187085- part1'
In the example output, note that applying the rules renames OCR device /dev/sdb1
to /dev/ocr1
.
Restart the udev
service by running the command start_udev
(/sbin/start_udev
). Restarting udev
applies the udev
rules to the devices, including the device file rules you have created. Use the command ls -l
command to ensure that the rules file has applied the new device names the rules file has applied. For example:
# start_udev # ls -l /dev | grep -e 'ocr1\|vote1' brw-r----- 1 root oinstall 8, 17 Oct 29 15:31 ocr1 brw-rw---- 1 oracle oinstall 8, 65 Oct 29 15:31 vote1
Perform the following steps to bind raw devices using the udev device manager:
If the file /etc/udev/rules.d/60-raw.rules
does not exist, users do not need to create it. However, users can add rules file even if it exists, or create a new rules file with more meaningful name like 61-oracleraw.rules
for the raw devices used with Oracle installations. For example:
# touch /etc/udev/rules.d/60-raw.rules
or
# touch /etc/udev/rules.d/61-oracleraw.rules
Add the udev
raw binding rules to the raw devices rules file you created. For example:
vi /etc/udev/rules.d/61-oracleraw.rules # Raw bind to Oracle Clusterware devices ACTION=="add", KERNEL=="sd*", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="360a98000686f6959684a453333524174", RUN+="/bin/raw /dev/raw/raw1 %N" ACTION=="add", KERNEL=="sd*", PROGRAM=="//sbin/scsi_id -g -u -s %p", RESULT=="360a98000686f6959684a453333524179", RUN+="/bin/raw /dev/raw/raw2 %N" t 29 15:31 vote1
Create a udev
raw permissions file /etc/udev/rules.d/65-raw-permissions.rule
s. For example:
# touch /etc/udev/rules.d/65-raw-permissions.rules
Using a text editor, add the udev
raw permission rules to the file /etc/udev/rules.d/65-raw-permissions.rules
. For example:
# Set permissions of raw bindings to Oracle Clusterware devices KERNEL=="raw1", OWNER="root", GROUP="oinstall", MODE="640" KERNEL=="raw2", OWNER="oracle", GROUP="oinstall", MODE="640"
Test the udev
rules by running the udevtest
command (/sbin/udevtest
) again to ensure that the rules are applied, and that they create proper permissions for Oracle Clusterware devices. For example:
# udevtest /block/sdb/sdb1 main: looking at device '/block/sdb/sdb1' from subsystem 'block' udev_rules_get_name: add symlink 'disk/by-id/scsi-360a98000686f69 59684a453333524174-part1' udev_rules_get_name: add symlink 'disk/by-path/ip-192.168.1.1:3260 -iscsi-iqn.1992-08.com.netapp:sn.84187085-part1' udev_node_mknod: preserve file '/dev/.tmp-8-17', because it has correct dev_t run_program: '/lib/udev/vol_id --export /dev/.tmp-8-17' run_program: '/lib/udev/vol_id' returned with status 4 run_program: '/sbin/scsi_id' run_program: '/sbin/scsi_id' (stdout) '360a98000686f6959684a45333 3524174' run_program: '/sbin/scsi_id' returned with status 0 udev_rules_get_name: rule applied, 'sdb1' becomes 'ocr1' udev_device_event: device '/block/sdb/sdb1' validate currently present symlinks udev_node_add: creating device node '/dev/ocr1', major = '8', minor = '17', mode = '0640', uid = '0', gid = '500' udev_node_add: creating symlink '/dev/disk/by-id/scsi-360a9800068 6f6959684a453333524174-part1' to '../../ocr1' udev_node_add: creating symlink '/dev/disk/by-path/ip-192.168.1.1 :3260-iscsi-iqn.1992-08.com.netapp:sn.84187085-part1' to '../../ocr1' main: run: 'socket:/org/kernel/udev/monitor' main: run: '/lib/udev/udev_run_devd' main: run: 'socket:/org/freedesktop/hal/udev_event' main: run: '/sbin/pam_console_apply /dev/ocr1 /dev/disk/by-id/scsi-36 0a98000686f6959684a453333524174-part1 /dev/disk/by-path/ip-192.168.1. 1:3260-iscsi-iqn.1992-08.com.netapp:sn.84187085-part1' main: run: '/bin/raw /dev/raw/raw1 /dev/.tmp-8-17'
Restart udev
to implement the rules you have created and tested. For example:
# start_udev
Verify Persistent Oracle Clusterware Storage Devices
Use the following commands to verify the persistent Oracle Clusterware storage devices:
Use the fdisk
command to check device naming. For example:
# fdisk -l /dev/ocr1 /dev/vote1 Disk /dev/ocr1: 261 MB, 261890048 bytes 9 heads, 56 sectors/track, 1014 cylinders Units = cylinders of 504 * 512 = 258048 bytes Disk /dev/ocr1 does not contain a valid partition table Disk /dev/vote1: 52 MB, 52403200 bytes 2 heads, 50 sectors/track, 1023 cylinders Units = cylinders of 100 * 512 = 51200 bytes Disk /dev/vote1 does not contain a valid partition table
Use the ls
command to check device ownership. For example:
# ls -l /dev | grep -ie 'ocr\|vote' brw-r----- 1 root dba 8, 17 Oct 29 15:31 ocr1 brw-rw---- 1 oracle dba 8, 65 Oct 29 15:31 vote1
Use the udevinfo
command to confirm unique SCSI device identifier mappings. For example:
# udevinfo -q all -n /dev/ocr1 P: /block/sdb/sdb1 N: ocr1 S: disk/by-id/scsi-360a98000686f6959684a453333524174-part1 S: disk/by-path/ip-192.168.1.1:3260-iscsi-iqn.1992-08.com.netapp:sn.87085-part1 E: ID_VENDOR=NETAPP E: ID_MODEL=LUN E: ID_REVISION=0.2 E: ID_SERIAL=360a98000686f6959684a453333524174 E: ID_TYPE=disk E: ID_BUS=scsi E: ID_PATH=ip-192.168.1.1:3260-iscsi-iqn.1992-08.com.netapp:sn.84187085
Use the raw
and ls
commands to confirm raw devices are bound. For example:
# raw -qa /dev/raw/raw1: bound to major 8, minor 17 /dev/raw/raw2: bound to major 8, minor 65 # ls -l /dev/raw/raw* crw-r----- 1 root oinstall 162, 11 Oct 30 12:54 /dev/raw/raw1 crw-r----- 1 oracle oinstall 162, 21 Oct 30 14:26 /dev/raw/raw2
After you have completed configuring and checking raw storage devices, you can proceed to install Oracle Clusterware and Oracle Real Application Clusters.
Oracle recommends that you move Oracle Clusterware files from raw devices to block devices.
See Also:
Oracle Database 2 Day + Real Application Clusters Guide for more information about relocating voting disks and Oracle Cluster Registry files.Oracle Database Client can be installed in the same Oracle Database home if both products are at the same release level. For example, you can install Oracle Database Client 10g Release 2 (10.2) into an existing Oracle Database 10g Release 2 (10.2) home. If you apply a patch set before installing the client, then you must apply the patch set again.
If you perform a Custom installation, then ensure that you install only the components covered by your license. You cannot install Standard Edition using Custom installation.
Oracle Storage Compatibility Program (OSCP) is no longer valid. Disregard any content about OSCP in the Oracle Database Installation Guide for Linux Itanium.
The following sections contain information about issues related to Oracle Database 10g and associated products:
SRVCTL and VIPCA Utilities Set the LD_ASSUME_KERNEL Parameter
Error While Loading Shared Library When SELinux is Enabled on Red Hat Enterprise Linux 5
MAX_IDLE_BLOCKER_TIME Does Not Work in Oracle RAC Environment
ONS Needs to be Started from Database Before Apache Standalone Installation
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.
This issue is fixed with the 10.2.0.5 patch set.
If the system uses a European language, you might see corrupted characters in Table of Contents of database tools, such as Database Configuration Assitant.
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
.
The following note applies if you are using Red Hat Enterprise Linux 4, Red Hat Enterprise Linux 5, 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, and Red Hat Enterprise linux 5, 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/raw
n
is an individual device file:
chown root:oinstall /dev/raw/rawn chmod 660 /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/raw
n
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/raw
n
is an individual device file:
chown oracle:oinstall /dev/raw/rawn chmod 660 /dev/raw/rawnmar
Installing Oracle Database 10g Release 2 (10.2.0.1) on Red Hat Enterprise Linux 4 Update 1 (2.6.9-11.ELsmp) produces a link error during creation of liborasdkbase.so.10.2
. The following error message is displayed:
INFO: gcc: INFO: /usr/lib/libstdc++.so.5: No such file or directory INFO: INFO: $OH/bin/genorasdksh: Failed to link liborasdkbase.so.10.2
This is because Oracle Database 10g Release 2 (10.2) requires Red Hat Enterprise Linux 3 libraries (/usr/lib/libstdc++.so.5
).
Workaround: Install the compatible libraries as follows:
rpm -ql compat-libstdc++-33-3.2.3-47.3
This issue is tracked with Oracle bug 4605635.
This section lists the issues with Cluster Verification Utility on Red Hat Enterprise Linux 4, Red Hat Enterprise Linux 5, SUSE Linux Enterprise Server 9, and SUSE Linux Enterprise Server 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, Red Hat Enterprise Linux 5, SUSE Linux Enterprise Server 9, and SUSE Linux Enterprise Server 10.
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
To use hugepages
or to accommodate the VLM window size on Red Hat Enterprise Linux 4, or Red Hat Enterprise Linux 5, you must increase the default maximum size of the per-process locked memory. To increase the per-process max locked memory limit, add the following lines to the /etc/security/limits.conf file
, where oracle
is the user that administers the database:
oracle soft memlock 3145728 oracle hard memlock 3145728
The current GNU C++ compiler version that OCCI supports with Red Hat Enterprise Linux 4.0 is GCC 3.2.3.
Workaround: Install Red Hat Enterprise Linux 4 with GCC 3.2.3.
Note:
For updates on GCC support, refer to the OCCI home page on OTN:http://www.oracle.com/technetwork/database/features/oci/index-090820.html
On Red Hat Enterprise Linux 4, Oracle XML Developer's Kit (XDK) is not supported with GCC. XDK is supported with Intel C++ compiler (ICC).
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.
The SRVCTL
and VIPCA
utilities set the environmental variable LD_ASSUME_KERNEL
. Setting this parameter on SUSE Linux Enterprise Server 10 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: Remove the LD_ASSUME_KERNEL
variable from the VIPCA
and SRVCTL
utilities. For the VIPCA
utility, alter the $CRS_HOME/bin/vipca
script on all nodes to remove LD_ASSUME_KERNEL
. After the "if" statement in line 123, add an unset
command to ensure LD_ASSUME_KERNEL
is not set as follows:
if [ "$arch" = "i686" -o "$arch" = "ia64" -o "$arch" = "x86_64" ] # then # LD_ASSUME_KERNEL=2.4.19 # export LD_ASSUME_KERNEL # fi unset LD_ASSUME_KERNEL
With the newly inserted line, root.sh
should be able to call VIPCA
successfully.
For the SRVCTL
utility, alter the $CRS_HOME/bin/srvctl
scripts on all nodes by adding a line, unset
LD_ASSUME_KERNEL
, after line 174 as follows:
LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL unset LD_ASSUME_KERNEL
Oracle recommends explicitly removing LD_ASSUME_KERNEL
and not commenting it out to handle cases where LD_ASSUME_KERNEL
might be set in the environment (login shell).
These files must also be altered after applying the 10.2.0.2 or 10.2.0.3 patch sets, as these patch sets still include those unnecessary LD_ASSUME_KERNEL
settings for Red Hat Enterprise Linux 5 or SUSE Linux Enterprise Server 10. This issue is fixed in the 10.2.0.4 patch sets.
SQL*Plus and Oracle Call Interface (OCI) program calls fail when selinux
is in Enforcing mode on Red Hat Enterprise Linux 5.
Workaround: Shift selinux
to Permissive mode on the system.
This issue is tracked with Oracle bug 6079461.
The use of the client static library is not supported.
Setting a value for MAX_IDLE_BLOCKER_TIME
feature of Resource manager does not work as expected in Oracle RAC environment.
Workaround: Set a value for MAX_IDLE_TIME
instead of setting a value for MAX_IDLE_BLOCKER_TIME
.
This issue is tracked with Oracle bug 6114355.
By default, the host name of a computer 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 host names from DHCP. This mapping may cause certain Oracle networking libraries to encounter errors when they attempt to resolve the host name of the computer. 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.
The host name must be included in the /etc/hosts
file. if you do not include the host name in this file, then the following error is displayed:
ORA-00600: internal error code, arguments: [keltnfy-ldmInit],[46],[1],[],[],[],[],[]
cvuqdisk-1.0.1-1.rpm (i386 rpm)
does not work as expected in Linux Itanium. You must install cvuqdisk-1.0.1-1.ia64.rpm
for cluster verification utility to verify the sharedness check of raw disks for 10.2 Linux Itanium.
When you use Oracle Universal Installer or Database Configuration Assistant in Japanese environment, you must set the LANG
environment variable to C.
This issue is tracked with Oracle bug 4764895.
If you plan to install Oracle HTML DB with Oracle HTTP Server from companion CD on the system where Oracle Database 10g has been installed, you must start ONS before you start the companion CD installation. This is required to prevent the companion CD installation from allocating the ports allocated to ONS Server in the Database installation.
This issue is tracked with Oracle bug 4701821.
When you connect to the database using Database Control, the page does not display the listener details.
Workaround: After installing Oracle Database 10g Release 2, you must shut down the Database Control with the emctl stop dbconsole command. Modify the targets.xml
file located in $ORACLE_HOME/hostname_SID/sysman/emd
directory so that the value of the machinename
field is the same for listener and database. Restart Database Control with the command emctl start. dbconsole
to display the listener details.
This issue is tracked with Oracle bug 6743916.
If you use a vendor clusterware with Oracle Clusterware and Oracle Real Application Clusters, then you must use the node names and host names registered with that vendor clusterware you have installed. Refer to the Certifications page on My Oracle Support (formerly OracleMetaLink) (https://support.oracle.com)for information about vendor clusterware supported for your Linux distribution.
This section lists the following corrections to installation guides for Linux Itanium.
Oracle RAC and the Hangcheck_reboot Parameter on Linux 2.6 Kernels
Incorrect Information About JPublisher and Oracle SQLJ Installation
In Oracle Database Installation Guide for Linux Itanium, Chapter 2, section "Configuring Kernel Parameters" , and in Oracle Database Quick Installation Guide for Linux Itanium, section "Configuring Kernel Parameters," update or add the following to the existing list of Kernel Parameters:
Parameter | Minimum Value | File |
---|---|---|
rmem_default |
262144 | /proc/sys/net/core/rmem_default |
rmem_max |
2097152 | /proc/sys/net/core/rmem_max |
wmem_max |
1048576 | /proc/sys/net/core/wmem_max |
ip_local_port_range |
Minimum: 9000
Maximum: 65500 Note: Ignore any Oracle Universal Installer warnings related to this parameter. |
/proc/sys/net/ipv4/ip_local_port_range |
aio-max-nr |
Maximum: 1048576
Note: This value limits concurrent outstanding requests and should be set to avoid I/O subsystem failures. |
/sbin/sysctl |
file-max |
327679
Note: If you have multiple databases on the same system or if you plan to consolidate multiple databases, then Oracle recommends using a higher value. |
/proc/sys/fs/file-max |
In Oracle Database Installation Guide for Linux Itanium, Chapter 2, section "Setting Shell Limits for the oracle User" , the values and the process to increase the shell limits is incorrect.
Update the following in the "Setting Shell Limits for the oracle User" section:
Add the following lines in the /etc/security/limits.conf
file:
oracle soft nproc 16384 oracle hard nproc 16384 oracle soft nofile 65536 oracle hard nofile 65536
Add or edit the following line in the /etc/pam.d/login
file, if it does not exist:
session required pam_limits.so
After you set the hard and soft values in the /etc/security/limits.conf
file, you do not have to modify the /etc/profile
file.
The following packages (or later versions) must be installed:
binutils-2.17.50.0.6-2.el5 compat-libstdc++-33-3.2.3-61 elfutils-libelf-0.125-3.el5 elfutils-libelf-devel-0.125-3.e15 gcc-4.1.1-52.el5 gcc-c++-4.1.1-52.el5 glibc-2.5-12 glibc-common-2.5-12 glibc-devel-2.5-12 glibc-headers-2.5-12 libaio-0.3.106-3.2 libaio-devel-0.3.106-3.2 libgcc-4.1.1-52.el5 libstdc++4.1.1-52.el5 libstdc++-devel-4.1.1-52.el5 make-3.81-1.1 systat-7.0.0-3.e15 unixODBC-2.2.11-7.1 unixODBC-devel-2.2.11-7.1
The following packages (or later versions) must be installed:
binutils-2.16.91.0.5 compat-libstdc++-5.0.7-22.2 gcc-4.1.0 glibc-2.4-31.63 glibc-devel-2.4-31.63 ksh-93r-12.9 libaio-0.3.104-14.2 libaio-devel-0.3.104-14.2 libelf-0.8.5-47.2 libgcc-4.1.0-28.4 libstdc++-4.1.0-28.4 libstdc++-devel-4.1.0-28.4 make-3.80-202.2 sysstat-6.0.2-16.4 unixODBC-2.2.11-21.4 unixODBC-devel-2.2.11-21.4
The following packages (or later versions) must be installed:
binutils-2.19.11.28 gcc-4.3-62.198 glibc-2.9-13.2 glibc-devel-2.9-13.2 ksh libaio-0.3.104-140.22 libaio-devel-0.3.104-140.22 libgcc-43-4.3.3-11.18 libstdc++-4.3.3-11.18 libstdc++-devel-4.3.3-11.18 make-3.81 sysstat-8.1.5-7.8
The system must be running the following kernel version (or a later version):
Red Hat Enterprise Linux 5.0
2.6.18-53.EL
SUSE Linux Enterprise Server 10
2.6.16-21
SUSE Linux Enterprise Server 11
2.6.27.19
In Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide for Linux, Chapter 2, "Pre-Installation Tasks," section "Oracle Clusterware Home Directory," incorrectly lists the path /u01/app/oracle/product/crs
as a possible Oracle Clusterware home path. A default Oracle base path is /u01/app/oracle
, and the Oracle Clusterware home must never be a subdirectory of the Oracle base directory.
A possible Oracle Clusterware home directory is in a path outside of the Oracle base directory. For example, if the Oracle base directory is u01/app/oracle
, then the Oracle Clusterware home can be an option similar to one of the following:
u01/crs/ /u01/crs/oracle/product/10/crs /crs/home
In Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide for Linux, Chapter 2, "Pre-Installation Tasks," section 2.6.1, "IP Address Requirements," the following text states that the virtual IP address (VIP) should respond to a ping
command:
During installation, OUI uses the ping
command to ensure that the VIP is reachable.
The preceding statement is incorrect. Before installation, the VIP address should be configured in DHCP or /etc/hosts
, or both, but it must not be assigned to a server that can respond to a ping
command.
In Oracle Database Administrator's Reference for UNIX-Based Operating Systems, Appendix H, "Database Limits," states the incorrect maximum value (63
) for the MAXINSTANCES
variable. The correct maximum limit for the variable is 1055
.
In Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide for Linux ,Chapter 2, "Pre-Installation Tasks", Section 2.16, "Checking the Configuration of the Hangcheck-timer Module", as initially released, information about the hangcheck_reboot
parameter is missing.
The hangcheck_reboot
parameter indicates to the hangcheck-timer whether it should restart the node. The hangcheck-timer restarts the node if the kernel fails to respond within the time determined by the sum of the hangcheck_tick
and hangcheck_margin
parameter values, and the hangcheck_tick parameter value is greater than or equal to 1
. If the hangcheck_reboot
parameter is set to zero (0
), then the hangcheck-timer does not restart the node.
By default, on 2.4 Linux kernels, the value of hangcheck_reboot
is 1
. However, on 2.6 kernels, the default value is 0
. In an Oracle RAC environment, you must set the hangcheck_reboot
parameter to 1
.
Set hangcheck_reboot=1
while loading the hangcheck-timer module. If you find that the cluster produces false node evictions, then increase the hangcheck_margin
parameter value, and retest the cluster.
The 10.2.0.4 patch release for Oracle Clusterware on Linux includes the Oracle Clusterware Process Monitor Daemon (oprocd
). It is started automatically by Oracle Clusterware to detect system hangs. When it detects a system hang, it restarts the hung node.
Review the following configuration information if you have installed the 10.2.0.4 patch set.
Oracle has found wide variations in scheduling latencies observed across operating systems and versions of operating systems. Because of these scheduling latencies, the default values for oprocd
can be overly sensitive, particularly under heavy system load, resulting in unnecessary oprocd
-initiated restarts (false restarts).
Oracle recommends that you address scheduling latencies with your operating system vendor to reduce or eliminate them as much as possible, as they can cause other problems.
To overcome these scheduling latencies, Oracle recommends that you set the Oracle Clusterware parameter diagwait
to the value 13
. This setting increases the time for failed nodes to flush final trace files, which helps to debug the cause of a node failure. You must shut down the cluster to change the diagwait
setting. However, if you prefer, you can use the default timing threshold for diagwait
. In that case, do not perform the procedure documented here.
If you require more aggressive failover times to meet more stringent service level requirements, then you should open a service request with Oracle Support to receive advice about how to tune for lower failover settings.
Note:
Changing thediagwait
parameter requires a clusterwide shutdown. Oracle recommends that you change the diagwait
setting either immediately after the initial installation, or during a scheduled outage.See Also:
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more informationTo change the diagwait
setting:
Log in as root
, and run the following command on all nodes, where CRS_home
is the home directory of the Oracle Clusterware installation:
# CRS_home/bin/crsctl stop crs
Enter the following command, where CRS_home
is the Oracle Clusterware home:
# CRS_home/bin/oprocd stop
Repeat this command on all nodes.
From one node of the cluster, change the value of the diagwait
parameter to 13 seconds by issuing the following command as root
:
# CRS_home/bin/crsctl set css diagwait 13 -force
Restart the Oracle Clusterware by running the following command on all nodes:
# CRS_home/bin/crsctl start crs
Run the following command to ensure that Oracle Clusterware is functioning properly:
# CRS_home/bin/crsctl check crs
In Oracle Database Administrator's Reference for UNIX-Based Operating Systems, chapter 1, section "DB_BLOCK_SIZE
Initialization Parameter", lists the incorrect value of DB_BLOCK_SIZE
parameter. The maximum value to which you can set the DB_BLOCK_SIZE
is 16 KB on Linux x86. It is 32 KB on all other UNIX platforms.
In Oracle Database documentation, Oracle inventory group is represented as oinstall
. However, it is not mandatory to use the same name, you can enter a different name for the group.
In Oracle Database Installation Guide for Linux Itanium, under Section 2.6, "Configure Kernel Parameters", subsection "Setting Shell Limits for the oracle User", the third list item has an incorrect reference to the /etc/profile
file. Ignore the entire third list item as making changes in the /etc/profile
file is not required.
In Oracle Database Administrator's Reference for UNIX-Based Operating Systems Guide, Appendix H, "Database Limits", Table H-2, "File Size Limits", states incorrect value of 20000 database blocks as control file size. The correct value is 25000 control file blocks with a block size of 4096 bytes.
In Oracle Database Vault Installation Guide for Linux Itanium, Chapter 4, section, "Installing Oracle Database 10g Products from the Companion CD," erroneously states that JPublisher and Oracle SQLJ are installed. The correct information is that JPublisher is not a part of Companion CD and Oracle SQLJ Demos are installed with the Companion CD instead of Oracle SQLJ.
In Oracle Database Companion CD Installation Guide for Linux Itanium, Chapter 1, section, "Products Available in the Oracle Database 10g Products Installation Type," erroneously states that JPublisher and Oracle SQLJ are installed. The correct information is that JPublisher is not a part of Companion CD and Oracle SQLJ Demos are installed with the Companion CD instead of Oracle SQLJ.
Note:
The SQLJ Demos are installed if Oracle SQLJ was installed before running the Companion CD installation.For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc
.
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info
or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
if you are hearing impaired.
Oracle Database Release Notes, 10g Release 2 (10.2) for Linux Itanium
B15673-14
Copyright © 2005, 2012, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.