Release Notes
Release 2 (9.2.0.4.0) for Linux x86
B13670-07
February 2006
These release notes accompany Oracle9i release 9.2.0.4. This release includes the 9.2.0.1 release and the patches for all previous 9.2.0.x patch sets. The latest patch set version which is included in this release is 9.2.0.4, and patches the following products only:
Java VM
JDBC
JPublisher
Networking
Online Application Processing (OLAP)
Oracle Core
Oracle Gateways
Oracle Intelligent Agent
Oracle interMedia
Oracle Internet Directory
Oracle Spatial
Oracle Text, formerly Oracle interMedia Text
Oracle UltraSearch
Oracle XDK
Oracle9i Database
Oracle9i Globalization
PL/SQL
Precompilers
SQLJ
SQL*Plus
XML Developer's Kit
This document contains the following sections:
Oracle9i release 2 (9.2.0.6) is certified on Red Hat Enterprise Linux 4. To install release 9.2.0.6 on Red Hat Linux Enterprise Server 4:
Review the issues in this section and complete the steps in the "Additional Required Pre-installation Tasks" section.
Review the other issues in these release notes.
Follow the instructions in the Oracle9i Release 2 (9.2.) Installation Guide for UNIX Systems to install Oracle9i release 9.2.0.4.
Follow the instructions in the Oracle9i Patch Set Notes Release 2 (9.2.0.6) for Linux x86 to install the release 9.2.0.6 patch set.
Complete the steps in the "Additional Required Post-installation Tasks" section .
The following sections contain addition information specific to installing Oracle9i release 9.2.0.6 on Red Hat Linux Enterprise Server 4:
Before installing Oracle9i release 2 (9.2.0.6) on Red Hat Enterprise Linux 4, you must perform the following steps:
The following packages (or later versions) must be installed:
compat-db-4.1.25-9 compat-gcc-32-3.2.3-47.3 compat-gcc-32-c++-3.2.3-47.3 compat-oracle-rhel4-1.0-3 compat-libcwait-2.0-1 compat-libgcc-296-2.96-132.7.2 compat-libstdc++-296-2.96-132.7.2 compat-libstdc++-33-3.2.3-47.3 gcc-3.4.3-9.EL4 gcc-c++-3.4.3-9.EL4 gnome-libs-1.4.1.2.90-44 gnome-libs-devel-1.4.1.2.90-44 libaio-devel-0.3.102-1 libaio-0.3.102-1 make-3.80-5 openmotif21-2.1.30-11 xorg-x11-deprecated-libs-devel-6.8.1-23.EL xorg-x11-deprecated-libs-6.8.1-23.EL
The compat-oracle-rhel4-1.0-3
and compat-libcwait-2.0-1
packages are available from OracleMetalink patch 4198954. To download patch 4198954:
Click Patches on the side of the OracleMetalink page.
Click Simple Search on the Select a Patch Search Area page.
Select Patch Number(s) in the Search By field.
Enter 4198954 in the Search By Patch Number(s) field.
Select Linux x86 in the Platform or Language field, then click Go.
On the patch download page, click Download.
Before you install Oracle9i release 9.2.0.6, you must download and unzip patch 4188455 from OracleMetalink:
http://metalink.oracle.com
To download and unzip patch 4188455:
Click Patches on the side of the OracleMetalink page.
Click Simple Search on the Select a Patch Search Area page.
Select Patch Number(s) in the Search By field.
Enter 4188455 in the Search By Patch Number(s) field.
Select Linux x86 in the Platform or Language field, then click Go.
On the patch download page, click Download.
The p4188455_10103_LINUX.zip
file is downloaded to your system. This file contains the oraparam.ini
file.
Unzip the p4188455_10103_LINUX.zip
file.
Optionally, copy the oraparam.ini
file to a different directory on your system, for example, /tmp
.
You must specify the full path to the oraparam.ini
file when you start the Installer.
Before starting Oracle Universal Installer, set the value of the LD_ASSUME_KERNEL environment variable to 2.4.19:
Bourne, Bash, or Korn shell:
$ LD_ASSUME_KERNEL=2.4.19; export LD_ASSUME_KERNEL
C shell:
$ setenv LD_ASSUME_KERNEL 2.4.19
See Also: For information about the LD_ASSUME_KERNEL environment variable, see document 243979.1, available from the OracleMetalink Web site:
|
After you complete the required post-installation tasks listed in the Oracle9i Patch Set Notes Release 2 (9.2.0.6) for Linux x86, you must complete the following tasks:
Download the patches for bugs 2617419 and 4190568 from OracleMetalink:
http://metalink.oracle.com
Log on to OracleMetalink.
Click Patches on the side of the OracleMetalink page.
Click Simple Search on the Select a Patch Search Area page.
Select Patch Number(s) in the Search By field.
Enter the bug numbers separated by a comma in the Search By Patch Number(s) field.
Select Linux x86 in the Platform or Language field, then click Go.
Select patch number 2617419 for release 10.1.0.2.
On the patch download page, click Download.
The p2617419_10102_GENERIC.zip
file is downloaded to your system. This file contains the opatch
utility.
Click the Back button in the browser.
Select patch number 4190568.
On the patch download page, click Download.
The p4190568_9206_LINUX.zip
file is downloaded to your system.
Change permission on the downloaded .zip
files as follows:
$ chmod o+rwx filename.zip
Switch user to the oracle user:
$ su- oracle
Unzip the p2617419_10102_GENERIC.zip
file.
Copy the extracted OPatch
directory to the Oracle home directory:
$ cp -a OPatch/ oracle_home_path/
Set the ORACLE_HOME environment variable to the Oracle home where you copied the OPatch
directory:
Bourne, Bash, or Korn shell:
$ ORACLE_HOME=oracle_home_path; export ORACLE_HOME
C shell:
% setenv ORACLE_HOME oracle_home_path
Add the $ORACLE_HOME/OPatch
directory to the list of directories specified in the PATH environment variable:
Bourne, Bash, or Korn shell:
$ PATH=$ORACLE_HOME/OPatch:$PATH ; export PATH
C shell:
% setenv PATH $ORACLE_HOME/OPatch:$PATH
Unzip the p4190568_9206_LINUX.zip
file.
Change directory to the directory where you unzipped the file, for example:
$ cd 4190568
Enter the following command to apply the patch:
$ opatch apply
Enter the following command to verify that the patch is applied:
$ opatch lsinventory
If you intend to use Direct I/O Support, you must download and apply patch 2448994, available on the OracleMetaLink Web site at:
http://metalink.oracle.com
To download patch 2448994:
Click Patches on the side of the OracleMetalink page.
Click Simple Search on the Select a Patch Search Area page.
Select Patch Number(s) in the Search By field.
Enter 2448994 in the Search By Patch Number(s) field.
Select Linux x86 in the Platform or Language field, then click Go.
On the patch download page, download the patch for the 9.2.0.6 release.
The Pro*COBOL and Pro*FORTRAN precompilers are not supported on Red Hat Enterprise Linux 4.
GNU C++ compiler (gcc) version 296 is not available on Red Hat Enterprise Linux 4. For this reason, OCCI and XDK++ are not available.
Legato Single Server Version (LSSV) is not Supported on Red Hat Enterprise Linux 4.
The "Using hugetlbfs on Red Hat Enterprise Linux AS 2.1 (Itanium) or SUSE Linux Enterprise Server 9" section in the Oracle Database 10g Release 10.1 Administrator's Reference should read as follows:
To enable Oracle Database to use large pages (sometimes called huge pages) on Red Hat Enterprise Linux AS 2.1 (Itanium), SUSE Linux Enterprise Server 9, or Red Hat Enterprise Linux 4, set the value of the vm.nr_hugepages
kernel parameter to specify the number of large pages that you want to reserve. You must specify a sufficient number of large pages to hold the entire SGA for the database instance.
To determine the required parameter value, divide the SGA size for the instance by the size of a large page, then round the result up to the nearest integer.
To determine the default large page size, enter the following command:
# grep Hugepagesize /proc/meminfo
For example, if /proc/meminfo
lists the large page size as 2 MB, and the total SGA size for the instance is 1.6 GB, then set the value for the vm.nr_hugepages
kernel parameter to 820 (1.6 GB / 2 MB = 819.2).
To use hugetlbfs
on Red Hat Enterprise Linux 4, you must increase the default maximum size of the per-process locked memory. To increase the per-process memory, 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
Before applying the Oracle9i release 2 (9.2.0.6) patchset to an Oracle Cluster Manager installation, review Oracle bug 4181942 and follow the instructions in the workaround section. Bug 4181942 is available on the OracleMetalink Web site:
http://metalink.oracle.com
To view bug 4181942:
Log on to OracleMetalink.
Click Bugs on the side of the OracleMetalink page.
Enter 4181942 in the Bug Number field, then click Search Bugs.
Before installing this release in a production environment, review the OracleMetaLink site. Oracle Support provides information about the status of issues discovered after this release is posted on OracleMetaLink. The information is available in document 189908.1, ALERT: Oracle9i Release 2 (9.2) Support Status and Alerts. To locate the document on OracleMetaLink, enter the document number in the search field, and click Search.
OracleMetaLink is available at the following URL
http://metalink.oracle.com/
If you are unable to access this site, then contact Oracle Support before installing this release in a production environment.
The following are the system requirements for this release:
Operating system requirement
SUSE Linux Enterprise Server (SLES) 8 and 9
Red Hat Enterprise Linux AS/ES 2.1 and 3
Hard disk space requirements
The space requirements listed on the Available Products window apply to installations that include a database. If you select the Software Only configuration type, then you require 3 GB.
The following information supplements the information on kernel parameters in the Oracle9i Installation Guide Release 2 (9.2.0.1.0) for UNIX Systems.
SHMSEG
This kernel parameter is no longer accessible to users on current kernel distributions. It can be ignored.
SHMALL
Do not change the default value of this parameter. This replaces the instruction in the Oracle9i Installation Guide Release 2 (9.2.0.1.0) for UNIX Systems to change the value.
SHMMAX
Set this parameter to half the size of physical RAM available on your system. This value cannot exceed 4294967295.
For large system global area (SGA) sizes greater than 1.8 GB, choose one of the following:
Run the following command as the root
user to mount the shared memory file system each time you reboot your system.
# mount -t shm shmfs -o nr_blocks=8g/dev/shm
Use the Automounter to run the shared memory file system command automatically as follows:
Edit the /etc/fstab
file as the root
user to include the following line:
shm /dev/shm shmfs nr_blocks=8g 0 0
The following sections list the software requirements for supported operating systems:
The following software is required for installation on Red Hat Enterprise Linux 2.1:
Linux kernel version: 2.4.9 errata 34 (e.34) or higher
Glibc version: glibc 2.2.4-32
Required operating system packages:
make-3.79
openmotif-2.1.30
gcc-2.96-128
gcc-c++-2.96-128
libstdc++-2.96-128
The following software is required for installation on Red Hat Enterprise Linux 3:
Linux kernel version: 2.4.21-15
Glibc version: glibc 2.3.2-95.20
Required operating system packages:
gcc-3.2.3-34
make-3.79.1
openmotif21-2.1.30-8
setarch-1.3-1
compat-db-4.0.14-5
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
gnome-libs-1.4.1.2.90-34.1
Before starting the Installer, set the environment as follows:
To ensure that the Oracle software uses the version 296 gcc
and g++
executables, enter the following commands:
% mv /usr/bin/gcc /usr/bin/gcc323 % mv /usr/bin/g++ /usr/bin/g++323 % ln -s /usr/bin/gcc296 /usr/bin/gcc % ln -s /usr/bin/g++296 /usr/bin/g++
The hostname
command should return the fully qualified host name as follows:
% hostname hostname.domainname
If any Java packages are installed on the system, unset the Java environment variables. For example, unset JAVA_HOME.
The oracle
account used to install Oracle9i release 9.2.0.4 should not have the Oracle installation-related variables set by default. For example, do not set ORACLE_HOME, PATH, LD_LIBRARY_PATH to include Oracle binaries in .profile
, .login
, and /etc/profile.d
.
If you are using the hugemem
kernel, enter the following command:
$ setarch i386
You do not have to enter this command if you are using the uniprocessor, smp
and boot
kernels.
The following software is required for installation on SLES 8:
Linux kernel version: 2.4.21-138
Required operating system packages:
gcc-3.2.2-38
glibc-2.2.2-124
make-3.79.1
openmotif-2.2.2-124
The following software is required for installation on SLES 9:
Linux kernel version: 2.6.5-7.97
Required operating system packages:
glibc-2.3.3
gcc-3.3.3
gcc-c++-3.3.3
libaio-0.3.98
libaio-devel-0.3.98
make-3.80
openmotif-libs-2.2.2-519.1
orarun-1.8-109
In addition to the environment variables listed in the Oracle9i Installation Guide for UNIX Systems, before starting the Installer set the following environment variables:
Note: You must set the LD_ASSUME_KERNEL and LD_PRELOAD environment variables before you run the Installer or any other Java-based Oracle utilities. |
Set the LD_ASSUME_KERNEL environment variable:
Bourne, Bash, or Korn shell:
$ LD_ASSUME_KERNEL=2.4.21 ; export LD_ASSUME_KERNEL
C shell:
% setenv LD_ASSUME_KERNEL 2.4.21
Set the LD_PRELOAD environment variable:
Bourne, Bash, or Korn shell:
$ LD_PRELOAD=/usr/lib/libInternalSymbols.so ; export LD_PRELOAD
C shell:
% setenv LD_PRELOAD /usr/lib/libInternalSymbols.so
Note: ThelibInternalSymbols.so library is part of the orarun package.
|
This section provides information about the following topics:
During installation you will be prompted to insert additional CD-ROMs from the set that make up Oracle9i release 2 (9.2.0.4.0). After inserting the requested disk, change the path in the Disk Location text box to specify the CD-ROM mount point directory, if necessary.
As it is necessary to insert and eject more than one CD-ROM during installation, do not launch Oracle Universal Installer by running the runInstaller
script from a shell where the current working directory is the CD-ROM mount point. Also do not launch the Oracle Universal Installer by clicking on the script in a File Manager window. To launch the Oracle Universal Installer, use the full CD-ROM path in the command syntax as follows:
cdrom_mount_path/runInstaller
In the previous command, cdrom_mount_path corresponds to the directory where the CD-ROM is mounted.
Review the following information before running Database Configuration Assistant. If you use Database Configuration Assistant to create a database, you must change the SYS and SYSTEM passwords at the end of the configuration process. This is a new security procedure designed to protect access to your data.
If you are upgrading from an Oracle release 8.0.6 database to Oracle9i release 2 (9.2.0.4.0) and you have Oracle interMedia installed on your system, then you cannot use Database Migration Assistant. You must migrate the database manually. For information on manual database migration, refer to Oracle9i Database Migration Release 2 (9.2).
To upgrade from Oracle8i release 8.0.6 to Oracle9i release 2 (9.2.0.4.0), use the following procedure:
Upgrade the Linux operating system kernel on your system to the values indicated in the Oracle9i Installation Guide Release 2 (9.2.0.1.0) for UNIX Systems.
Start the Oracle 8.0.6 database.
Run the Oracle Universal Installer as instructed in the Oracle9i Installation Guide Release 2 (9.2.0.1.0) for UNIX Systems.
Select the 8.0.6 database when prompted to select a database for upgrading.
For installation with a response file, the path to the response file must be the full path on the system. The Oracle Universal Installer does not handle relative paths properly.
An unzip utility is provided with Oracle9i release 2 (9.2.0.4.0) for uncompressing Oracle patches downloaded from OracleMetaLink. The utility is located in the following directory:
$ORACLE_HOME/bin/
While loading the __libc_wait@GLIBC_2.0
symbol, 920x runInstaller fails on Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4.
Workaround: Download and apply the ARU 4897983
patch to resolve this issue.
This issue is tracked with Oracle bug 3006854.
The following sections contain information about issues related to Oracle9i and associated products:
Enabling Large Pages on Red Hat Enterprise Linux 2.1 and SUSE Linux Enterprise Server 8
Oracle Real Application Clusters and Oracle Data Guard During a Network Outage
ALTER TABLE SET COLUMN UNUSED not Supported by Logical Standby Databases
Logical Standby Databases on the Same Node as the Primary Database
Initially Starting Logical Standby Fails with Error ORA-1652
SQL Apply Does Not Support Tables with Function-based or Descending Indexes
On Red Hat Linux, the /etc/hosts
file defines the local host name to the loopback entry by default. This setting causes Oracle Intelligent Agent to fail to stop or restart. To correct this problem, enter the system IP address as the first line in the /etc/hosts
file using the following format:
IP address
hostname.domain hostname
For example:
123.456.789.012 db.acme.com db
If you want to use a large SGA size, set the USE_INDIRECT_DATA_BUFFERS parameter to TRUE.
Enabling large pages can improve scalability by reducing virtual memory overhead in the kernel. However, memory resources in the large page pool cannot be swapped, so you must be sure that your system has sufficient memory.
Note: Using the bigpages parameter is supported only on Red Hat Enterprise Linux 2.1 and SUSE Linux Enterprise Server 8. It is not available or supported on Red Hat Enterprise Linux 3 or SUSE Linux Enterprise Server 9. |
To use the large pages feature, you must determine the bigpages parameter value. To determine this value, convert the size of the instance's SGA to megabytes, and round up by 4 MB. Use the following example as a guide:
Note: You can determine the size of the SGA by using the SHOW SGA command in SQL*Plus or by using theipcs command.
|
If the SGA is 2.7 GB:
Determine the bigpages value as follows:
bigpages = 2.7 * 1024 = 2764.8
Round the value up by 4 to 2768.
Depending on your boot loader, perform one of the following steps:
LILO:
Add the bigpages
option to the appropriate image section in the /etc/lilo.conf
file:
append = "bigpages=2768MB"
Run /sbin/lilo
.
Restart the system.
GRUB:
Add the bigpages
option to the kernel command in the /etc/grub.conf
file, for example:
kernel /vmlinuz-2.4.9 root=/dev/hda5 bigpages=2768MB
Restart the system.
To enable the large pages feature, set the value of the shm-use-bigpages kernel parameter in the /etc/sysctl.conf
file to either 1 or 2, depending on whether you are using the extended buffer cache feature, and set the USE_INDIRECT_DATA_BUFFERS initialization parameter to TRUE in the parameter file:
If you are not using the extended buffer cache (VLM), set the value to 1:
kernel.shm-use-bigpages = 1
If you are using the extended buffer cache (VLM), set the value to 2 to configure the bigpages memory pool to include the memory allocated in /dev/shm
:
kernel.shm-use-bigpages = 2
Enter the following command to set the parameter values:
# sysctl -p /etc/sysctl.conf
Start up Oracle Database.
Depending on your distribution of Linux, use the instructions in one of the following sections to increase the SGA address space:
Red Hat Enterprise Linux 2.1 and SUSE Linux Enterprise Server 8 and 9
To increase the SGA address space on Red Hat Enterprise Linux 2.1 and SUSE Linux Enterprise Server 8 and 9:
If necessary, log in as the oracle
user.
In the $ORACLE_HOME/rdbms/lib
directory, enter the following commands:
$ genksms -s 0x15000000 > ksms.s $ make -f ins_rdbms.mk ksms.o $ make -f ins_rdbms.mk ioracle
Note: If Oracle Database does not start after completing this procedure, or if there are runtime memory errors, then increase the hexadecimal number specified in the first command. For example, if the 0x15000000 value prevents Oracle Database from starting, specify the value 0x20000000. Lowering this value increases the SGA address space, but could decrease the PGA address space. |
Enter the following command to determine the process ID of the oracle
user's shell process:
$ echo $$
The number returned is the process ID.
Switch user to root
:
$ su - root
Enter the following commands to change the mapped base setting for the oracle
user's shell process, where pid
is the process ID identified in step 3:
# echo 268435456 > /proc/pid
/mapped_base
Enter exit
to return to the oracle
user's shell process, and start the Oracle Listener and Oracle Database.
Note: All Oracle processes need to get this modified mapped base value. Starting the listener from the shell that has the modified mapped base allows client connections to connect properly. |
Red Hat Enterprise Linux 3 and 4
To increase the SGA address space on Red Hat Enterprise Linux 3 and 4, follow these steps:
If necessary, log in as the oracle
user.
In the $ORACLE_HOME/rdbms/lib
directory, enter the following commands:
$ genksms -s 0x15000000 > ksms.s $ make -f ins_rdbms.mk ksms.o $ make -f ins_rdbms.mk ioracle
Start Oracle Database.
On SLES 9, Oracle Messaging Gateway requires Java Development Kit (JDK) version 1.3.1_09 or higher.
If this version of JDK or a higher version is not installed, install it on the system. Do not install it in the Oracle home directory. When you configure Oracle Messaging Gateway, you must specify the appropriate paths to this JDK installation in the listener.ora
and mgw.ora
files.
If you are an Oracle E-Business Suite customer and you want to upgrade your Oracle E-Business Suite release 11i database server to this patch set, then you must check the latest certification status and Interoperability Notes available on the OracleMetaLink Web site at:
http://metalink.oracle.com
The following items apply to Oracle Streams:
The optional capture process of Oracle Streams requires the SHARED_POOL_SIZE initialization parameter be set to a minimum value of 100 MB, and the database be running in ARCHIVELOG mode. The database initialization parameter, TRANSACTION_AUDITING, must be set to its default value. The default value is TRUE.
The first capture process created on a database builds the Oracle Streams dictionary. If the initial dictionary build is interrupted, then an error indicating that the dictionary is invalid may occur. The typical cause of an interrupted dictionary build is a shutdown abort
operation. All other shutdown modes will wait for the dictionary build to complete. If you encounter this error, then drop and recreate the capture process.
JMS Types and XMLType access to the Oracle Streams queue table is not enabled by default to minimize the impact of bug 2248652 which causes export of the Streams queue table to fail. Users can enable this access by calling the DBMS_AQADM.ENABLE_JMS_TYPES (queue_table) procedure, where the VARCHAR2 parameter queue_table is the name of the queue table. This procedure should be invoked after the call to DBMS_STREAMS_ADM.SET_UP_QUEUE.
Note: Databases dependent on the Export utility as their backup strategy should avoid enabling this access. |
A capture process cannot capture changes made to tables that use function-based or descending indexes. If a capture process tries to capture a change to a table that uses a function-based or descending index, then it writes the LCR that caused the error into its trace file, raises an ORA-00902 error, and becomes disabled.
Oracle Streams support for CLOB datatypes in multibyte character sets is limited to non-variable size multibyte character sets. If the character set uses a variable-width multibyte encoding scheme, then Streams does not support CLOB datatypes. Refer to the Oracle9i Database Globalization Support Guide for additional information about encoding schemes.
The TRANSACTION_AUDITING initialization parameter must be set to TRUE for Oracle Streams to function correctly.
A capture process cannot process logs that include DML update statements using the BUFFER hint. The BUFFER hint disables supplemental logging for the update operation which causes the capture process to stop.
The following issues apply to Oracle Data Guard:
Be careful to use the correct case when supplying schema and tables names to the DBMS_LOGSTDBY package. For example, the following statements show incorrect and correct syntax for a SKIP procedure that skips changes to OE.TEST.
The following is the incorrect statement:
EXECUTE DBMS_LOGSTDBY.SKIP('DML', 'oe', 'test', null);
Because the names are specified with lowercase characters, the transactions that update these columns will still be applied to the logical standby database.
The following is the correct statement:
EXECUTE DBMS_LOGSTDBY.SKIP('DML', 'OE', 'TEST', null);
When subheaps are in use, logical standby databases should be explicitly configured to specify an SGA usage, which is a portion of one subheap. This is known bug 2435087. A good value is 25 percent of the subheap size. For example, if the subheap size is 160 MB, then the following statement would set SGA usage for the redo cache to 25 percent of that value:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 40)
Currently, skipping GRANT DDL for a particular object fails to skip the command when using the DBMS_LOGSTDBY.SKIP('GRANT','MYSCHEMA','MYOBJ') procedure.
This may result in "ORA-00942: table or view does not exist" failures, or other failures because the object was not created but the grant
attempt was still made. The same applies to GRANT even if the request was to skip all SCHEMA_DDL. The safest way to work around this problem is simply to check the events table, and find the failing Transaction ID values. Provide those to DBMS_LOGSTDBY.SKIP_TRANSACTION, and restart SQL apply operations.
Section 7.2.2 "Failover Operations Involving a Physical Standby Database" in Oracle Data Guard Concepts and Administration, Oracle part number A96653-02, should include the following note:
Note: After issuing "ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;" to perform a failover to a physical standby database, log transport services attempt to send the last log file being archived to all destinations in the Data Guard configuration, including deferred destinations defined with LOG_ARCHIVE_DEST_STATE_n=DEFER. This can result in the following error being returned for the deferred destinations:Error 12514 Creating archive log file to '<service_name>' To avoid receiving this error, replace the deferred fields with blanks by issuing the following statement before initiating the failover: 'ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=" " SCOPE=MEMORY; '" |
This section describes the wait events that monitor the performance of the log transport modes specified on the primary database with the ARCH, log writer (LGWR) SYNC, and LGWR ASYNC attributes on the LOG_ARCHIVE_DEST_n initialization parameter. These wait events are related to known bug 2435087. The following wait events and associated timing information are displayed by the V$SYSTEM_EVENT view:
The following wait events are for standby destinations configured with the ARCH attribute:
ARCH wait on ATTACH: This wait event monitors the amount of time spent by all archiver processes to spawn an RFS connection.
ARCH wait on SENDREQ: This wait event monitors the amount of time spent by all archiver processes to write the received redo to disk as well as open and close the remote archived redo log files.
ARCH wait on DETACH: This wait event monitors the amount of time spent by all archiver processes to delete an RFS connection.
The following wait events are for standby destinations configured with the log writer (LGWR) SYNC attributes:
LGWR wait on ATTACH: This wait event monitors the amount of time spent by all log writer processes to spawn an RFS connection.
LGWR wait on SENDREQ: This wait event monitors the amount of time spent by all log writer processes to write the received redo to disk as well as open and close the remote archived redo log files.
LGWR wait on DETACH: This wait event monitors the amount of time spent by all log writer processes to delete an RFS connection.
The following wait events are for standby destinations configured with the log writer (LGWR) ASYNC attributes:
LNS wait on ATTACH: This wait event monitors the amount of time spent by all network servers to spawn an RFS connection.
LNS wait on SENDREQ: This wait event monitors the amount of time spent by all network servers to write the received redo to disk as well as open and close the remote archived redo log files.
LNS wait on DETACH: This wait event monitors the amount of time spent by all network servers to delete an RFS connection.
LGWR wait on full LNS buffer: This wait event monitors the amount of time spent by the LGWR process waiting for the network server (LNS) to free up ASYNC buffer space. If buffer space has not been freed in a reasonable amount of time, availability of the primary database is not compromised by allowing the archiver process (ARCn) to transmit the redo log data. This wait event is not relevant for destinations configured with the LGWR SYNC=PARALLEL attributes.
Note: This wait event is not relevant for destinations configured with the LGWR SYNC=NOPARALLEL attributes. |
The following wait events are for standby destinations configured with either the log writer (LGWR) ASYNC or LGWR SYNC=PARALLEL attributes:
LGWR wait on LNS: This wait event monitors the amount of time spent by the LGWRprocess waiting to receive messages on IPC channels from the network server.
LNS wait on LGWR: This wait event monitors the amount of time spent by the network server waiting to receive messages on IPC channels from the LGWR process.
LGWR-LNS wait on channel: This wait event monitors the amount of time spent by the LGWR process or the network server processes waiting to receive messages on IPC channels.
If errors occur when log transport services on the primary database try to transmit redo data to a standby destination that is configured with the LGWR ASYNC or LGWR SYNC attributes (on the LOG_ARCHIVE_DEST_n initialization parameter), log transport services will eventually use the archiver process (ARCn) to transmit the redo data to the standby destination.
For example, timing out messages in alert log with LGWR ASYNC. When the standby destination is configured with the LGWR ASYNC attributes, it is possible to reach "ASYNC buffer full" conditions when the network to the standby destination cannot keep up with the redo generation rate on the primary database. When this occurs, the following message is written to the Alert log:
Timing out on NetServer %d prod=%d,cons=%d,threshold=%d"
This message indicates that the standby destination configured with the LGWR ASYNC attributes encountered an "ASYNC buffer full" error condition. When this occurs, log transport services will automatically stop using the network server process to transmit the redo data and instead use the archiver process (ARCn). This change occurs automatically; no specific user action is necessary to make this happen. However, you may be able to avoid the "ASYNC buffer full" error condition by increasing the ASYNC buffer size.
Note: This does not apply to Oracle Data Guard configurations running in maximum protection mode. It is only for configurations running in the maximum availability or maximum performance modes. Refer to Oracle Data Guard Concepts and Administration for complete information about the Oracle Data Guard protection modes. |
Oracle Text uses the INSO filter during the indexing of binary documents. This filtering technology is based on Stellent Chicago Corporation's HTML Export technology and is licensed from Stellent Chicago Corporation.
INSO 7.5 is included with this release and supports additional platforms and document types. A full list of supported platforms and document types is documented in Note 212584.1 in OracleMetaLink.
Customers running Oracle Applications release 11.5.7 or 11.5.8 with Advanced Queuing Configured with multi-consumer queues may encounter corruption problem after upgrading their database to 9.2.0.x from any Oracle8i database.
Note: Refer to note 231074.1 on OracleMetaLink for details and workaround. |
Event 10499 available in this release allows customers to revert to the earlier behavior of NUMBER datatypes that have no explicit setting of their scale value. Any non-zero setting of the event level will enable the old behavior.
Prior to the introduction of this event, server code could return zero for the scale if a NUMBER datatype was created without specifying the scale. Other code paths would return -127. With this event, all code paths return -127, as this is the correct behavior.
Client applications may rely on the previous (incorrect) behavior. Typically, client applications will test for a scale of -127 to distinguish between NUMBER and FLOAT datatypes. It is not sufficient to test the scale alone to distinguish between these two datatypes, one needs to test for a scale of -127 and a non-zero precision to identify a FLOAT.
Client applications that rely on the old behavior can still work as before if the event is set but will need to be corrected prior to upgrading to the next major release of the Oracle database.
This section describes Oracle Data Guard configurations running in maximum protection mode with physical standby databases. If you configured Oracle Data Guard to support a primary database in a Oracle Real Application Clusters environment and the primary database is running in maximum protection mode, the network outage between the primary database and all of its physical standby databases will disable the primary database until the network connection is restored. The maximum protection mode dictates that if the last participating physical standby database becomes unavailable, processing halts on the primary database.
If you expect the network to be down for an extended period of time, consider changing the primary database to run in either the maximum availability or the maximum performance mode until network connectivity is restored. If you change the primary database to maximum availability mode, then it is possible for a lag between the primary and standby databases, but you gain the ability to use the primary database until the network problem is resolved.
If you choose to change the primary database to the maximum availability mode, then it is important to use the following procedures to prevent damage to your data.
Perform the following steps if the network goes down, and you want to change the protection mode for the Oracle Real Application Clusters configuration.
Shut down the physical standby database.
Follow the instructions in Oracle Data Guard Concepts and Administration to change the mode from the maximum protection mode to either maximum availability or maximum performance mode.
Open the Oracle Real Application Clusters primary database for general access.
Restart the network.
Shut down the Oracle Real Application Clusters primary database.
Mount the primary database without opening it for general access.
Mount the physical standby database.
Change mode on the Real Application Clusters primary database from its current maximum availability or maximum performance mode to the maximum protection mode.
Open the Oracle Real Application Clusters primary database.
Do not issue the ALTER TABLE SET COLUMN UNUSED
statement on a primary database that has logical standby databases. Using the ALTER TABLE
statements to set a column unused may fail and return the "ORA-26689: column datatype mismatch in LCR" error. After this error occurs, use the DBMS_LOGSTDBY.INSTANTIATE_TABLE procedure for the table listed in the DBA_LOGSTDBY_EVENTS view, and restart SQL apply operations.
While the DBMS_LOGSTDBY.INSTANTIATE_TABLE procedure will refresh the logical standby database's copy of the table, all subsequent updates to the table will fail. The following is the workaround for this problem:
Drop the column on the primary database.
Run the DBMS_LOGSTDBY.INSTANTIATE_TABLE PL/SQL procedure to re-create the table on the logical standby database.
Restart the SQL apply operations on the logical standby database.
For this release of Oracle Data Guard, logical standby databases do not support creating nested tables. Attempting to create a nested table on the logical standby database will result in the "ORA-02320: failure in creating storage table for nested table column" error.
If the DDL statement causes SQL apply operations to stop on the logical standby database, then provide the transaction ID information (obtained by querying the DBA_LOGSTDBY_EVENTS view) to the DBMS_LOGSTDBY.SKIP_TRANSACTION procedure, and restart SQL apply operations. Although you can create the table on the logical standby database, rows will not be maintained for it.
SQL statements, such as CREATE TABLE tablename AS SELECT * FROM bar@dblink
, may fail on logical standby databases. Avoid issuing this type of statement, because there are many errors that can arise from this type of operation.
When the statement is executed on the logical standby database, it accesses the database link at that time and it is not possible to know if the information on the logical standby database is the same as it was at the time the statement was executed on the primary database. For example, additional columns may have been added or dropped that would make it impossible to apply the rows that follow. Assuming the network was set up so that the initial creation succeeded, you might see the following error: "ORA-26689: column datatype mismatch in LCR" for a table containing nested table columns. Also, the "ORA-02019: connection description for remote database not found" error may be returned if the database link or the TNS service was undefined on the logical standby database.
When this happens, use the DBMS_LOGSTDBY.INSTANTIATE_TABLE procedure for the table being created, and restart SQL apply operations.
If a logical standby database is located on the same computer system as the primary database, it is likely both Oracle instances have access to the same directory structure. There are Oracle commands that reuse datafiles. If Oracle commands that reuse datafiles are applied on the primary database, then the commands may also be applied on the logical standby database. If that happens while the primary database is shut down, then it is possible for the logical standby database to claim the file as part of its database and possibly cause damage to the primary database.
For this reason only, Oracle recommends using the following settings when running the primary and logical standby databases on the same computer system.
EXECUTE DBMS_LOGSTDBY.SKIP('ALTER TABLESPACE');
If SQL apply operations fail on a logical standby database and return the "ORA-01749 you may not GRANT/REVOKE privileges to/from yourself" error message, then it is probably caused by an attempt to execute a GRANT DDL
statement to grant a privilege or a role to SYS
. To verify this is the problem, query the DBA_LOGSTDBY_EVENTS view to see the failed DDL statement along with its transaction ID shown in the XIDUSN, XIDSLT, XIDSQN columns in the view. The following describes how to fix the problem:
Execute the DBMS_LOGSTDBY.GUARD_BYPASS_ON PL/SQL procedure.
Execute the failed DDL statement.
Enter the XIDUSN, XIDSLT, XIDSQN column values as parameters to the DBMS_LOGSTDBY.SKIP_TRANSACTION PL/SQL procedure.
Restart SQL apply operations on the logical standby database.
Materialized views must be refreshed separately on a logical standby database using the GUARD_BYPASS_ON and GUARD_BYPASS_OFF procedures of the DBMS_LOGSTDBY package. For example:
EXECUTE DBMS_LOGSTDBY.GUARD_BYPASS_ON; EXECUTE DBMS_MVIEW.REFRESH ( 'BMVIEW', 'F', '',TRUE,FALSE,0,0,0,FALSE); EXECUTE DBMS_LOGSTDBY.GUARD_BYPASS_OFF;
If you are using the DBMS_LOGSTDBY.APPLY_SET procedure but you are not using the default value FULL for the TRANSACTION_CONSISTENCY parameter, then you should stop SQL apply operations before refreshing materialized views on the logical standby database.
See Also: Refer to the Oracle9i supplied PL/SQL packages and types reference for more information about the DBMS_LOGSTDBY package. |
LogMiner uses temporary tables to stage its internal dictionary as it is mining it out of the redo stream. If the temporary tablespace is not configured adequately, such as it does not have enough space or is not backed up by a temporary file, then the initialization phase of a logical standby database will fail with the following errors:
ORA-1652: unable to extend segment by 512 in tablespace TEMP ORA-01332: internal Logminer Dictionary error
To work around the problem, increase the size of the temporary tablespace and start the logical standby database.
Occasionally when performing Data Guard broker operations, you may see the following message in the Data Guard configuration log file:
RSM: error in accessing metadata.
You can ignore this message. It is benign and does not indicate any operational problem with the broker or the databases included in the broker configuration.
When connecting to a database using the Data Guard command-line interface (DGMGRL), a connect string that includes multiple domains separated by dots may result in the "invalid username/password; logon denied" message being returned. For example, the following CONNECT
command can be problematic:
DGMGRL> CONNECT SYS/CHANGE_ON_INSTALL@standby.acme.com
Use one of the following solutions to work around this problem:
Use double quotation marks, such as the following:
DGMGRL> CONNECT SYS/CHANGE_ON_INSTALL@"standby.acme.com"
Use connect strings that do not have multiple domains. This solution might require that you edit the tnsnames.ora
file.
In Appendix B, Section B.3.2 "Determining Whether an Archive Gap Exists," the text recommends querying the V$ARCHIVE_GAP view to determine whether there is an archive gap.
Instead, you should query the V$ARCHIVED_LOG and V$LOG views, which more accurately reflect if there is a gap on a particular standby destination.
For example, the following query shows there is a difference in the RECD and SENT sequence numbers for the destination specified by DEST_ID=2, indicating that there is a gap:
SQL> SELECT MAX(R.SEQUENCE#) LAST_SEQ_RECD, MAX(L.SEQUENCE#) LAST_SEQ_SENT 2> FROM V$ARCHIVED_LOG R, V$LOG L 3> WHERE R.DEST_ID=2 AND L.ARCHIVED='YES'; LAST_SEQ_RECD LAST_SEQ_SENT ------------- ------------- 7 10
Use the following query to determine the names of the archived redo logs on the local system that must be copied to the standby system that has the gap:
SQL> SELECT NAME FROM V$ARCHIVED_LOG 2> WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10; NAME -------------------------------------------------------------------------- /primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc /primary/thread1_dest/arcr_1_10.arc
The DBMS_LOGSTDBY PL/SQL procedure does not support the BLOB data type even though BLOB data types are supported by logical standby databases. Also, the order of the parameters for the INSTANTIATE_TABLE procedure is incorrect in the Oracle Data Guard Concepts and Administration and in the Oracle9i Supplied PL/SQL Packages and Types Reference. The correct parameter order is as follows:
DBMS_LOGSTDBY.INSTANTIATE_TABLE schema_name IN VARCHAR2, table_name IN VARCHAR2, dblink IN VARCHAR2);
Logical standby databases do not support tables with function-based or descending indexes in Oracle9i release 2. This information should have been included in Oracle Data Guard Concepts and Administration, Oracle part number A96653-02. There is currently no workaround for this problem.
The following issues apply to this release:
The CORE version in V$VERSION shows 9.2.0.3 after a successful upgrade of the database. This does not cause any problems, and can be ignored by the user.
While creating the database using the Database Configuration Assistant during 'Creating Data Dictionary Views', the Database Configuration Assistant returns the ORA-29807 error. You can ignore this error, it does not cause any problems.
Using a database link to connect to a read-only database to select data from a view fails, and returns errors ORA-4052, ORA-604, ORA-372, ORA-1110, and ORA-2063. You cannot use a database link to select data from a view using a cursor loop.
Workaround
Avoid using the database link to query views using a cursor loop. This problem only occurs with a view. It does not occur when using a SELECT statement directly from the view using a cursor loop to select from a table.
When using the Oracle Streams Wizard, through Oracle Management Server or in standalone mode, to configure replication, the generated scripts are incorrect and may produce errors such as "ORA-26687 Instantiation SCN not set" or "ORA-1403 no data found". Contact Oracle Support Services for an Oracle Enterprise Manager and Oracle Management Server patch that will produce the correct scripts. Use the bug numbers as a patch reference.
Scrollable ResultSet returns 3 times NCHAR character byte size when database Ncharset is UTF8. This problem occurs with JDBC Thin driver only.
Oracle Data Guard Concepts and Administration, Oracle part number A96553-02, only describes how to instantiate a logical standby database for a single-instance primary database. To register a log for multiple threads of an Oracle Real Applications Clusters primary database, use the following query in place of the one that is documented in "Section 4.2.2, Step 8 Identify the latest archived redo log:"
SQL> SELECT NAME FROM V$ARCHIVED_LOG 2> WHERE FIRST_CHANGE# <= (SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG 3> WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO') 4> AND NEXT_CHANGE# (SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG 5> WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO') NAME -------------------------------------------------------------------------- /arch/prim/arch_-1306740637_2_0000000004.log /arch/prim/arch_-1306740637_1_0000000278.log tpcc SQL> SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG 2> WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO' MAX(FIRST_CHANGE#) ------------------ 1378506
The query will return the sequence number that should be specified in "Section 4.2.17, Register the Archived Redo Log and Start SQL Apply Operations."
If you want to use Oracle Capacity Planner, download the patch for this bug from OracleMetalink.
For asynchronous I/O support on Red Hat Enterprise Linux 3, download the patch for this bug from OracleMetalink.
To resolve issues with Intelligent Agent startup (agentctl start
), download the patch for this bug from OracleMetalink.
Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/
.
Accessibility of Code Examples in Documentation
Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.
TTY Access to Oracle Support Services
Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the United States of America 24 hours a day, seven days a week. For TTY support, call 800.446.2398.
Oracle 9i Release Notes, Release 2 (9.2.0.4.0) for Linux x86
B13670-07
Copyright © 1996, 2006, Oracle. All rights reserved.
The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States 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, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software—Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.