7.1 Review Known Preinstallation Issues

Review the information in the following sections. If any of the issues apply to the Oracle installation, follow the instructions before installing the patch set.

• Upgrading Oracle E-Business Suite Databases

• Upgrading Installations that use Physical or Logical Standby Databases

• Upgrading Installations that use Java Virtual Machine or Oracle interMedia

• Upgrading Oracle Clusterware

• Notes to Oracle OLAP Users

• Disabling Oracle Database Vault

http://metalink.oracle.com

http://metalink.oracle.com

http://metalink.oracle.com

7.2 Identify the Oracle Database Installation

This is not a complete software distribution. You must install it in an existing Oracle Database 10g Oracle home. To identify Oracle home directories, view the/etc/oratab file.

If you are installing this patch set on an existing Oracle Real Application Cluster 10g release 10.2.0.x installation, you must run Oracle Universal Installer from the same node from which the Oracle Database software was installed.

7.3 Check Postrelease Updates

Before installing this patch set in a production environment, review document 316900.1, ALERT: Oracle 10g release 2 (10.2) Support Status and Alerts, available on the OracleMetaLink Web site:

http://metalink.oracle.com

To locate this document:

1. Log on to OracleMetaLink.

2. Click Advanced at the top of the OracleMetaLink page.

3. Enter 316900.1 in the Document ID field, then click Submit.

This document is created by Oracle Support Services and provides information about the status of issues discovered after this patch set was released. If you are unable to access this site, then contact Oracle Support Services before installing this patch set in a production environment.

7.4 Download and Extract the Installation Software

To download and extract the patch set installation software:

1. Download the p6810189_10204_LINUX.zip patch set installation archive to a directory that is not the Oracle home directory or under the Oracle home directory.

2. Enter the following command to unzip and extract the installation files:

   $ unzip p6810189_10204_LINUX.zip
   

7.5 Update Oracle Time Zone Definitions

The 10.2.0.4 patch set includes an update to the Oracle time zone definitions to Version 4. This version of the time zone definitions includes the changes to daylight saving time in the USA in 2007 and other updates.

In the Oracle database the TIMESTAMP WITH LOCAL TIME ZONE (TSLTZ) and TIMESTAMP WITH TIME ZONE (TSTZ) data types and the TZ_OFFSET function select the time zone information from the time zone files.

It may be necessary to take action on existing TIMESTAMP WITH LOCAL TIME ZONE (TSLTZ) and TIMESTAMP WITH TIME ZONE (TSTZ) data or to re-apply DST patches afterwards.

For full overview please see OracleMetaLink document 553812.1 "Actions for the DSTv4 update in the 10.2.0.4 patchset".

1. When patching from a lower 10.2 release or upgrading from 10.1.0.X directly to 10.2.0.4, check the current version of the Oracle time zone definitions with the following command:

   SELECT version FROM v$timezone_file;
   

   • If this query reports version 4, no action is required; in this case, continue with steps described in section 7.6.

   • If this reports a version lower or higher then 4, see OracleMetalink document 553812.1 "Actions for the DSTv4 update in the Release 10.2.0.4 patchset".

2. On upgrading from Release 9i directly to Release 10.2.0.4, see OracleMetaLink document 553812.1 "Actions for the DSTv4 update in the 10.2.0.4 patchset."

3. On upgrading from Release 8.1.7 directly to Release 10.2.0.4, no action is required because Release 8.1.7 has no timezone data stored; in this case continue with steps described in section 7.6

7.6 Set the ORACLE_HOME and ORACLE_SID Environment Variables

Enter the following commands to set the ORACLE_HOME and ORACLE_SID environment variables:

• Bourne, Bash, or Korn shell:

  $ ORACLE_HOME=Oracle_home
  $ ORACLE_SID=sid
  $ export ORACLE_HOME ORACLE_SID
  

• C shell:

  % setenv ORACLE_HOME Oracle_home
  % setenv ORACLE_SID sid
  

In these examples, Oracle_home is the Oracle home directory where the Oracle Database 10g installation that you want to upgrade is installed, and sid is the system identifier of the database that you want to upgrade. For Oracle RAC installations, sid is generally the sid prefix and the instance number. For example, ORCL1.

7.7 Stop All Processes

Go to the following sections based on the Oracle Database installation type:

• Stopping All Processes for a Single Instance Installation

• Stopping All Processes for an Oracle Clusterware Installation

• Stopping All Processes for an Oracle RAC Installation

7.8 Back Up the System

Oracle recommends that you create a backup of the Oracle Inventory, Oracle 10g home and Oracle 10g Database before you install the patch set. If you are planning to apply this patch to Oracle RAC, ensure that you create a backup of these components on all nodes before applying the patch.

8.1 Installing the Oracle Database 10g Patch Set Interactively

To install the Oracle Database 10g patch set interactively:

OUI-10091: There are no patches that need to be applied from the patch set Oracle Database 10g Release 2 Patch Set 3
10.2.0.4

1. Log in as the oracle user.

2. If you are not installing the software on the local computer, then run the following command on remote machine:

   • Bourne, Bash, or Korn shell:

     $ export DISPLAY=localhost:0.0
     

   • C shell:

     % setenv DISPLAY local_host:0.0
     

   In this example, local_host is the host name or IP address of the computer that you want to use to display Oracle Universal Installer.

   Now to enable X applications, run the following command on the machine that you want to use to display Oracle Universal Installer:

   $ xhost + [fully_qualified_remote_host_name]
   

3. Enter the following commands to start Oracle Universal Installer, where patchset_directory is the directory where you unpacked the patch set software:

   % cd patchset_directory/Disk1
   % ./runInstaller
   

4. On the Welcome screen, click Next.

5. On the Specify Home Details screen, select the name of the Oracle home that you want to update, or select the Path that you want to update from the list, then click Next.

6. If you are installing the patch set on an Oracle RAC cluster, click Next when the Selected Nodes screen appears.

7. On the Product-specific Prerequisite Checks screen, correct any reported errors, and click Next.

8. Enter details regarding the CSI Number, OracleMetaLink Account user name and Country code on the Oracle Configuration Manager Registration screen and click Next.

   
   

   Note: The registration and configuration can also be done manually after patchset installation. The OCM registration page appears only while applying 10.2.0.4 patch over existing DB instances alone.

   
   

9. On the Summary screen, click Install.

   This screen lists all of the patches available for installation.

10. When prompted, run the $ORACLE_HOME/root.sh script as the root user. If you are applying the patch set to an Oracle RAC installation, then run the root.sh script on each node of the cluster.

    
    

    Note: If you are applying this patch set to an Oracle Clusterware installation, then complete all of the steps displayed on the Oracle Universal Installer screen. The Oracle Clusterware installation instructions displayed on the Oracle Universal Installer screen are also available in the CRS_home/install/readme.txt file. When applying this patch set on an Oracle Clusterware home, Oracle Universal Installer prompts you to run the root102.sh script from $ORACLE_HOME/install. You must run this script as the root user on all nodes. Before you add a new node, ensure that you run rootpre.sh script as the root user on the new node.

    
    

11. On the End of Installation screen, click Exit, then click Yes to exit from Oracle Universal Installer.

8.2 Installing the Oracle Database 10g Patch Set Noninteractively

To install the Oracle Database 10g patch set noninteractively:

1. Copy the response file template provided in the response directory where you unpacked the patch set archive file.

2. Edit the values for all fields labeled as <Value Required> as described by the comments and examples in the template.

   
   

   Note: For Oracle RAC installations, make sure the CLUSTER_NODES variable specifies all of the nodes used in the original Oracle RAC installation.

   
   

3. To run Oracle Universal Installer, enter a command similar to the following, where response_file is the full path to the response file that you edited:

   $ ./runInstaller -silent -responseFile response_file
   

4. After the installation, run the $ORACLE_HOME/root.sh script as the root user. If you are applying the patch set to an Oracle RAC installation, then run the root.sh script on each node of the cluster.

   
   

   Note: If you are applying this patch set to an Oracle Clusterware installation, then complete all the steps in the CRS_home/install/readme.txt file. You must run this script as the root user on all nodes.

   
   

9.1 Updating Oracle Time Zone Definitions

Based on the result you had in Section 7.5, "Update Oracle Time Zone Definitions" regarding the DST (Oracle time zone definitions):

• If the DST version in 7.5 was 4, no action is required.

• If f the DST version in 7.5 was higher than 4, reapply the version of DST patches as described in OracleMetaLink document 553812.1 "Actions for the DSTv4 update in the 10.2.0.4 patchset."

• If the DST version in 7.5 was lower then 4, restore TSTZ data from backup (if any). For more information, see OracleMetaLink document 553812.1 "Actions for the DSTv4 update in the 10.2.0.4 patchset."

• If you are upgrading from Release 8.1.7 directly to Release 10.2.0.4, no action is required.

9.2 Upgrading Earlier Oracle Database to Oracle Database 10g Release 2 (10.2.0.4)

Review the following sections before upgrading an earlier Database to Oracle Database 10g release 2 (10.2.0.4):

• Upgrading Earlier Oracle Database Releases to Oracle Database 10g Release 2 (10.2.0.4)

• Upgrading a Release 9.2 Database Not Using Oracle Label Security

9.3 Upgrading Oracle Database 10g Release 10.2.0.x to Oracle Database 10g Release 10.2.0.4

See one of the following sections for upgrading an Oracle Database 10g release 10.2.0.x to Oracle Database 10g release 10.2.0.4:

• Upgrading a Release 10.2 Database using Oracle Database Upgrade Assistant

• Manually Upgrading a Release 10.2 Database

Oracle Database 10.2 Upgrade Information Utility    02-04-2008 11:48:11
.
**********************************************************************
Database:
**********************************************************************
--> name:       X102040
--> version:    10.2.0.1.0
--> compatible: 10.2.0.1
--> blocksize:  8192
.
**********************************************************************
Tablespaces: [make adjustments in the current environment]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
.... minimum required size: 505 MB
.... AUTOEXTEND additional space required: 15 MB
--> UNDOTBS1 tablespace is adequate for the upgrade.
.... minimum required size: 401 MB
.... AUTOEXTEND additional space required: 376 MB
--> SYSAUX tablespace is adequate for the upgrade.
.... minimum required size: 265 MB
.... AUTOEXTEND additional space required: 15 MB
--> TEMP tablespace is adequate for the upgrade.
.... minimum required size: 58 MB
.... AUTOEXTEND additional space required: 38 MB
--> EXAMPLE tablespace is adequate for the upgrade.
.... minimum required size: 69 MB
.
**********************************************************************
Update Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
WARNING: --> "shared_pool_size" needs to be increased to at least 167772160
WARNING: --> "java_pool_size" needs to be increased to at least 67108864
.
**********************************************************************
Components: [The following database components will be upgraded orinstalled]
**********************************************************************
--> Oracle Catalog Views         [upgrade]  VALID
--> Oracle Packages and Types    [upgrade]  VALID
--> JServer JAVA Virtual Machine [upgrade]  VALID
--> Oracle XDK for Java          [upgrade]  VALID
--> Oracle Java Packages         [upgrade]  VALID
--> Oracle Text                  [upgrade]  VALID
--> Oracle XML Database          [upgrade]  VALID
--> Oracle Workspace Manager     [upgrade]  VALID
--> Oracle Data Mining           [upgrade]  VALID
--> Messaging Gateway            [upgrade]  VALID
--> OLAP Analytic Workspace      [upgrade]  VALID
--> OLAP Catalog                 [upgrade]  VALID
--> Oracle OLAP API              [upgrade]  VALID
--> Oracle interMedia            [upgrade]  VALID
--> Spatial                      [upgrade]  VALID
--> Oracle Ultra Search          [upgrade]  VALID
--> Oracle Label Security        [upgrade]  VALID
--> Expression Filter            [upgrade]  VALID
--> EM Repository                [upgrade]  VALID
--> Rule Manager                 [upgrade]  VALID
PL/SQL procedure successfully completed.

9.4 Running changePerm.sh Script on an Oracle Database Server Home

During patch set installation, all new files and directories are created with restricted access, by default. Users or third party applications with a different group identifier from that of the database, which try to access client-side utilities or libraries in the database home, will see permission errors when trying to access these files or directories. Perform the following steps to change the permissions:

1. Change to the install directory by using the following command:

   $ cd $ORACLE_HOME/install
   

2. Run changePerm.sh and specify the patched server Oracle home location, before accessing client-side utilities or libraries in the database home.

   
   

   Note: If you are applying patch to Oracle RAC home, then you will need to run this script on all the nodes.

   
   

9.5 Enabling Oracle Database Vault

For installations with Oracle Database Vault, complete the following steps:

1. Restart the database:

   For a single-instance database, use the following commands:

   sqlplus SYS "AS SYSDBA"
   Enter password:
   SQL> shutdown immediate
   SQL> STARTUP
   

   For an Oracle Real Application Clusters (RAC) database, use the following commands:

   $ORACLE_HOME/bin/srvctl stop database -d db_name
   $ORACLE_HOME/bin/srvctl start database -d db_name
   

2. Connect AS SYSDBA and run the following SQL statements:

   SQL> DROP FUNCTION DVSYS.REALM_SDML_AUTHORIZED ;
   SQL> DROP PROCEDURE DVSYS.SYNCHRONIZE_POLICY_FOR_OBJECT;
   SQL> DECLARE
                 CURSOR stmt IS
                          SELECT u.name, o.name, r.pname
                              FROM user$ u, obj$ o, rls$ r
                          WHERE u.user# = o.owner#
                              AND r.obj# = o.obj#
                              AND bitand(r.stmt_type,65536) > 0;
    
                          object_schema VARCHAR2(32) := NULL;
                          object_name VARCHAR2(32) := NULL;
                          policy_name VARCHAR2(32) := NULL;
    
                          BEGIN
                           OPEN stmt;
                             LOOP
                                  FETCH stmt INTO object_schema, 
                                                  object_name, 
                                                  policy_name;
                                  EXIT WHEN stmt%NOTFOUND;
                                  DBMS_RLS.DROP_POLICY(
                                  '"'||object_schema||'"',
                                  '"'||object_name||'"',
                                  '"'||policy_name||'"');
                             END LOOP;
                           CLOSE stmt;
                          END;
                         /
   

3. Run DVCA to reconfigure Database Vault. Use the following syntax:

   $ORACLE_HOME/bin/dvca -action option -oh oracle_home -jdbc_str
       jdbc_connection_string -owner_account DV_owner_account_name
       [-acctmgr_account DV_account_manager_account_name]
       [-logfile ./dvca.log] [-nodecrypt]
   

   Where:

   - action: The action to perform. option creates the Database Vault schema objects, creates the DV_OWNER account and the optional DV_ACCTMGR account, and deploys the Database Vault Administrator application.

   - oh: The Oracle home for the database

   - jdbc_str: The JDBC connection string used to connect to the database. For example, jdbc:oracle:oci:@orcl1, where orcl1 is the net service name in the tnsnames.ora file ($ORACLE_HOME/network/admin/tnsnames.ora).

   - owner_account: Oracle Database Vault Owner account name

   - acctmgr_account: (Optional) Oracle Database Vault Account Manager user

   - logfile: Optionally, specify a log file name and location. You can enter an absolute path or a path that is relative to the location of the $ORACLE_HOME/bin directory

   - nodecrypt: Reads plaintext passwords as passed on the command line. You must use this option if you are passing plaintext passwords to the command.

   
   

   Note: You are prompted to enter the SYS, Database Vault Owner, and Database Vault Account Manager passwords.

   
   
   
   

   See Also: Oracle Database Vault Installation Guide, 10g Release 2 (10.2) for Linux x86, Appendix C "Running DVCA After Creating a Database Vault Database" for more options available with the dvca -action option command

   
   

4. Run Oracle Database Vault Configuration Assistant (DVCA) by using the dvca -action enable option. This enables the Database Vault triggers. Use the following syntax:

   dvca -action enable
            -service service_name
            -owner_account DV_owner_account_name 
           [-logfile ./dvca.log]
           [-nodecrypt]
    
       Enter SYS password: sys_password
       Enter owner password: owner_password 
   

   See Step 6 for details of the options used in the command.

5. Lock the DVSYS account. Use the following SQL statements:

   SQL> CONNECT SYS "AS SYSDBA"
   Enter password:
   SQL> ALTER USER DVSYS ACCOUNT LOCK;
   

6. Shut down the database.

   To stop a single-instance database, use the following commands:

   sqlplus SYS "AS SYSDBA"
   Enter password:
   SQL> shutdown immediate
   

   For an Oracle Real Application Clusters (RAC) database, use the following command:

   $ORACLE_HOME/bin/srvctl stop database -d db_name
   

7. Relink the Oracle executable to turn on the Oracle Database Vault option. Use the following commands:

   cd $ORACLE_HOME/rdbms/lib
       make -f ins_rdbms.mk dv_on
       cd $ORACLE_HOME/bin
       relink oracle
   

   
   

   Note: For an Oracle Real Application Clusters (RAC) database, you must repeat the preceding commands on all nodes.

   
   

8. Start the database.

   For a single-instance database, use the following commands:

   sqlplus SYS "AS SYSDBA"
   Enter password:
   SQL> startup
   

   For an Oracle Real Application Clusters (RAC) database, use the following command:

   $ORACLE_HOME/bin/srvctl start database -d db_name
   

9. If you wish to disable connections with SYSDBA privileges, then re-create the password file with the nosysdba=y and force=y flags. Use the following syntax:

   orapwd file=$ORACLE_HOME/dbs/orapwSID password=password force=y nosysdba=y
   

   Here SID is the Oracle system identifier (SID) of the database, and password is the password for the SYS account.

9.6 Configuring Oracle Configuration Manager in a Cloned Oracle Home

If you have installed and configured Oracle Configuration Manager in the original Oracle home directory, then complete the following procedure:

1. In the cloned Oracle home, remove all the subdirectories of the $ORACLE_HOME/ccr/hosts directory to remove the previously configured hosts.

2. In the cloned Oracle home, run the following command:

   $ configCCR -a
   

If you have installed Oracle Configuration Manager in the original Oracle home but have not configured it, then run the following command to configure it in the cloned Oracle home:

$ setupCCR

11.1 Removing the Patch Set Software for Single Instance Installation

Perform the following steps for removing the patch set from the 10.2.0.4 patch release:

1. Use SQL*Plus to log in to the database as the SYS user with SYSDBA privileges:

   $ sqlplus /NOLOG SQL> CONNECT SYS AS SYSDBA Enter password:SYS_password SQL> SHUTDOWN IMMEDIATE SQL> EXIT

2. Take a backup of the following file in 10.2.0.4 Oracle home directory:

   $ ORACLE_HOME/rdbms/admin/catrelod.sql
   $ ORACLE_HOME/network/admin/tnsnames.ora
   

3. Enter the following SQL*Plus commands:

   $ cd $ORACLE_HOME
   $ sqlplus /NOLOG
   SQL> CONNECT SYS AS SYSDBA
   Enter password:SYS_password
   SQL> STARTUP DOWNGRADE
   SQL> SPOOL downgrade.out
   SQL> @?/rdbms/admin/catdwgrd.sql
   SQL> SPOOL OFF
   SQL> SHUTDOWN IMMEDIATE
   SQL> EXIT
   

4. Review the downgrade.out file for errors.

5. Restore the Oracle10g installation and Central Inventory (see /etc/oraInst.loc) that you backed up before applying the patch set.

6. After restoring the original Oracle home, copy the saved version of catrelod.sql script into the restored Oracle home rdbms/admin directory. Also copy the saved version of 10.2.0.4/network/admin/tnsnames.ora directory into the restored Oracle home /network/admin/tnsnames.ora directory, and then perform the following steps:

   $ sqlplus /NOLOG
   SQL> CONNECT SYS AS SYSDBA
   Enter password:SYS_password
   SQL> STARTUP DOWNGRADE
   SQL> SPOOL catrelod.out
   SQL> @?/rdbms/admin/catrelod.sql
   SQL> SPOOL OFF
   SQL> SHUTDOWN IMMEDIATE
   

7. Review the catrelod.out file for errors.

8. Start the database and recompile the remaining invalid objects:

   SQL> STARTUP
   SQL> @?/rdbms/admin/utlrp.sql
   

11.2 Removing the Patch Set Software for Oracle RAC Installation

Perform the following steps for removing the patch set from the 10.2.0.4 patch release:

1. Use SQL*Plus to log in to the database as the SYS user with SYSDBA privileges:

    $ sqlplus /NOLOG
    SQL> CONNECT SYS AS SYSDBA
   Enter password:SYS_password
   

2. Set the CLUSTER_DATABASE initialization parameter to FALSE:

   
   

   Note: If the system uses an initialization parameter file, change the value of the CLUSTER_DATABASE initialization parameters to TRUE in the initialization parameter file (initsid.ora).

   
   

   SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile; 
   

3. Exit SQL*Plus and shut down the database:

   $ srvctl stop database -d db_name
   

4. Take a backup of the following files in 10.2.0.4 Oracle home directory:

   $ ORACLE_HOME/rdbms/admin/catrelod.sql
   $ ORACLE_HOME/network/admin/tnsnames.ora
   

5. Enter the following SQL*Plus commands:

   $ sqlplus /NOLOG
   SQL> CONNECT SYS AS SYSDBA
   Enter password:SYS_password
   SQL> STARTUP DOWNGRADE
   SQL> SPOOL catdwgrd.out
   SQL> @?/rdbms/admin/catdwgrd.sql
   SQL> SPOOL OFF
   SQL> SHUTDOWN IMMEDIATE
   SQL> EXIT
   

6. Restore the Oracle10g installation and Central Inventory (see /etc/oraInst.loc) that you backed up before applying the patch set on both the nodes.

7. After restoring the original Oracle home, copy the saved version of catrelod.sql script into the restored Oracle home rdbms/admin directory. Also copy the saved version of 10.2.0.4/network/admin/tnsnames.ora directory into the restored Oracle home /network/admin/tnsnames.ora directory, and then perform the following steps:

   $ sqlplus /NOLOG
   SQL> CONNECT SYS AS SYSDBA
   Enter password:SYS_password
   SQL> STARTUP DOWNGRADE
   SQL> SPOOL catrelod.out
   SQL> @?/rdbms/admin/catrelod.sql
   SQL> SPOOL OFF
   SQL> SHUTDOWN IMMEDIATE
   

8. Review the catrelod.out file for errors.

   
   

   Note: Ignore the ORA-29844 and ORA-31085 errors found in the catrelod.out file. These errors are tracked with Oracle bugs 4758112 and 4425495 respectively. After reloading the 10.2.0.2 release, the version numbers for Oracle Data Mining and Oracle OLAP Analytic Workspace remain at 10.2.0.4. These issues are tracked with Oracle bugs 4758695 and 4751917.

   
   

9. Start the database and recompile the remaining invalid objects:

   SQL> STARTUP
   SQL> @?/rdbms/admin/utlrp.sql
   

10. Set the CLUSTER_DATABASE initialization parameter to TRUE:

    
    

    Note: If the system uses an initialization parameter file, change the value of the CLUSTER_DATABASE initialization parameters to TRUE in the initialization parameter file (initsid.ora).

    
    

    SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile;
    SQL> SHUTDOWN
    SQL> EXIT
    

11. Start the database:

    $ srvctl start database -d db_name
    

    
    

    Note: Option for removing Oracle Clusterware patch set is not available in 10.2.0.4. This issue is tracked with Oracle bug 5598010.

    
    

14.1 Oracle Scheduler External Jobs

If you use Oracle Scheduler, that is, (DBMS_SCHEDULER) external jobs on Linux, and have modified the owner or group of the extjob executable, then this patch set will reset these changes.

Beginning with Oracle Database release 10.2.0.4, the supported way to change the user or group that external jobs run as is to modify the externaljob.ora file in the rdbms/admin directory. This file is owned by the root user and only the root user can modify this file. Changes to this file take effect immediately and do not require restarting the database.

14.2 Upgrading Preconfigured Standard Edition Databases

If you are using an Oracle Database release 10.2.0.2 preconfigured Standard Edition database, then the database contains the following components that are not supported by the Standard Edition:

• Oracle Data Mining

• Oracle OLAP Catalog

• Oracle OLAP Analytic Workspace

• Oracle OLAP API

• Oracle Spatial

The catupgrd.sql script does not run the patch scripts for these components. It sets the component STATUS to OPTION OFF in the DBA_REGISTRY view. The original versions of the dictionary objects for the components remain in the database but the catupgrd.sql script does not apply the patch to them.

14.3 The Welcome Page of Oracle Database Upgrade Assistant Displays Incorrect Version

The Welcome page of Oracle Database Upgrade Assistant displays incorrect version of Oracle 9i. Oracle 9i Release 9.1.0 should read as Oracle 9i Release 9.0.1.

This issue is tracked with Oracle bug 6695802.

14.4 Non-ASCII Characters on Help Navigation Are Not Displayed Properly with UTF-8 encoding

Non-ASCII characters on Help Navigation are not displayed properly and appear to be distorted for most Java GUI conventional components when the operating system locale is UTF-8 enabled, such as Oracle Database Configuration Assistant, Oracle Database Upgrade Assistant, NetCA, NetMgr, Oracle Directory Manager, Oracle WM, and Locale Builder. The issue slightly impacts five translated European languages and three Asian languages, except Japanese. This issue only affects the help navigation tree and has no effects on the help topic window.

Workaround:

UTF-8 is the default encoding of the operating system locale on Linux 4.0 and for the European languages on Linux 3.0. You should change the default locale to the one with native encoding to see the correct characters on the Help Navigation tree. The following is the list of the Oracle recommended locales:

• de_DE.iso88591 for German

• fr_FR.iso88591 for French

• it_IT.iso88591 for Italian

• es_ES.iso88591 for Spanish

• pt_BR.iso88591 for Brazilian Portuguese

• zh_CN.gb18030 for Simplified Chinese

• zh_TW.big5 for Traditional Chinese

• ko_KR.euckr for Korean

Complete one of the following tasks to change the locale:

• Run the following commands to alter the locale on a terminal session temporally:

  $ LANG=locale
  $ export LANG
  

  Use this terminal to start the components to see only the help topics. You should start components for other tasks in other terminals that have the default locale.

• To alter the system default locale as the operating system administrator, edit the UTF-8 entry to a native encoding in the /etc/sysconfig/i18n file. Then reboot the computer.

• To alter the locale in the user login environment file, such as .bash_profile. Add the following lines to the login profile file:

  $ LANG=locale
  $ export LANG
  

With the modified operating system locale encoding, the operating system file system related operations that use non-ASCII characters are affected. For example, creating or renaming a file with non-ASCII file name on operating system is affected by this modification. If you want to keep consistency with the default operating system locale encoding in the file system operations, you should avoid using non-ASCII characters when the workaround second or third is applied, or apply the first workaround to see the help only on the changed locale.

This issue is addressed in Oracle Database 11g (11.1.0.6). Therefore, Oracle recommends you to alter the system default locale or the locale in the user login environment file back to the default encoding (UTF-8) after Oracle Server is upgraded to Oracle Database 11g.

This is tracked with Oracle bug 6503286.

14.5 Running Oracle Database Upgrade Assistant on a Single Node Oracle RAC Installation

Oracle Database Upgrade Assistant fails during postinstallation upgrade on a single node and displays the following error message:

ORA-32001: write SPFILE requested but no SPFILE specified at startup

Workaround:

1. Start the database with the NOMOUNT option:

   $ sqlplus /NOLOG
   SQL> CONNECT SYS AS SYSDBA
   Enter password:SYS_password
   SQL> STARTUP NOMOUNT
   

2. Create SPFILE from PFILE by entering the following command where pfile_location is usually $ORACLE_BASE/admin/db_name/pfile for Optimal Flexible Architecture compliant database:

   SQL> CREATE SPFILE=SHARED_LOCATION/SPFILE.ORA FROM PFILE=pfile_location/init.ora
   

3. Shut down the database:

   SQL> SHUTDOWN IMMEDIATE
   SQL> EXIT
   

4. Clear the contents of PFILE located at ORACLE_BASE\ORACLE_HOME\dbs\initsid.ora and set the value of SPFILE as SHARED_LOCATION\SPFILE.ORA.

5. Run Oracle Database Upgrade Assistant:

   $ $ORACLE_HOME/bin/dbua
   

This issue is tracked with Oracle bug 5531643.

14.6 Refresh From OracleMetaLink Job Fails in Oracle Enterprise Manager Database Control

If you attempt the Refresh from OracleMetaLink job in Oracle Enterprise Manager Database Control, then it displays the following error:

Exception trying to access the repository. java.sql.SQLException:
ORA-12899: value too large for column
"SYSMAN"."MGMT_ARU_PRODUCTS"."PRODUCT_NAME" (actual: 54, maximum: 50)

Workaround:

None. Oracle will release a one-off patch to address this issue.

This issue is tracked with Oracle bug 6755395.

14.7 The sysman Related Errors Are Listed in the oraInstall.err File

When you use Oracle Universal Installer to remove Oracle Database 10g Release 2 (10.2.0.4), some sysman related errors are listed in the oraInstall.err file.

Workaround:

These are benign errors and can be ignored.

This issue is tracked with Oracle bug 6363210.

14.8 Errors Displayed When Upgrading from Oracle Database 10g Release 2 (10.2.0.4)

When upgrading Oracle Database 10g Release 2 (10.2.0.4) to Oracle Database 11g Release 1 (11.1.0.6), the following errors are displayed:

ORA-06550: line 5, column 35:
ORA-06550: line 5, column 1:
ORA-00001: unique constraint
(SYSMAN.PARAMETERS_PRIMARY_KEY) violated
ORA-06512: at "SYSMAN.MGMT_TIME_SYNC", line 108
Oracle_Server.log:ORA-06512: at "SYSMAN.MGMT_TIME_SYNC", line 166
Oracle_Server.log:ORA-06512: at line 2 

Workaround:

These errors do not result in any data loss. Therefore, you can ignore these errors.

This issue is tracked with Oracle bug 6705429.

14.9 Incorrect Database Version is Displayed on the Oracle Enterprise Manager Database Control Page After Downgrading

If you downgrade the database from Oracle Database 10g Release 2 (10.2.0.4) to an earlier version, Oracle Enterprise Manager Database Control may not restart after the downgrade. However, the emctl start dbconsole command may appear to have started the database console, but you cannot access the database console pages. The emctl status dbconsole command displays that the database console in fact has not started.

Workaround:

This issue is most likely a result Oracle bug 4505434, which has been fixed in this release but exists in earlier releases. To address this issue, apply the patch for bug 4505434 for the database console version you downgraded to and restart the database console.

This issues is tracked with Oracle bug 6649954.

14.10 Benign Entry in the Silent Log File After Cloning the Database

An entry similar to the following is logged in the silent log file immediately after you clone the database:

File not found: $ Cloned_Oracle_home/ccr/new_ccr/ccr/bin/setupCCR

Workaround:

This entry in the log file is not a error and can be ignored.This issue is tracked with Oracle bug 6721838.

14.11 Incorrect Nodes Displayed in Cloned Oracle Clusterware

On a cloned Oracle Clusterware, the new node does not display the correct node from which you should run a command.

Workaround:

Run the following command to address this issue:

$ ./runInstaller -clone -silent ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME \ 
=Oracle_home_name n_storageTypeVDSK=2 n_storageTypeOCR=2 \
"sl_tableList={first_node:first_node_priv:first_node-vip, \
second_node:second_node_priv:second_node-vip}" \
s_ocrpartitionlocation=location_of_ocr s_votingdisklocation=location_of_voting_disk \
"ret_PrivIntrList={private_interconect_list}" INVENTORY_LOCATION=central_inventory_location -noConfig

This issue is tracked with Oracle bug 6754695.

14.12 Native Full Outer Join Implementation

To enable a new native full outer join implementation in the database, a user has to set the following underscore parameter:

_optimizer_native_full_outer_join =force

You can set this parameter for the system or for a specific session.

Besides dramatically improving the performance of a full outer join, the new implementation fixes a variety of issues, for examples a variety of ORA-942 (table or view doesn't exists) and ORA-4331 (unable to allocate string bytes of shared memory) errors.

This issue is tracked with Oracle bug 6322672.

14.13 Incorrect Oracle Workspace Manager Displayed After Upgrading to Oracle Database 11g

After upgrading Oracle Database 10g Release 2 (10.2.0.4) to Oracle Database 11g Release 1 (11.1.0.6), the Oracle Workspace Manager version is displayed as 10.2.0.4.3.

This issue is tracked with Oracle bug 6732811.

14.14 ASM Error is Displayed When Creating 10g Release 2 (10.2.0.1) Database on Oracle Clusterware (10.2.0.4)

If you are installing and creating an Oracle Database 10g Release 2 (10.2.0.1) database, which uses ASM storage, after upgrading Oracle Clusterware to version 10.2.0.4, then the following error may be displayed:

An error occurred while executing ASM queries.

Workaround:

This error is benign. Click Continue to proceed with the installation. There is no loss of functionality due to this error.

This issue is tracked with Oracle bug 6791427.

14.15 SETUPCCR Fails if Preset JAVA_HOME Points to an Invalid JDK Home

When CCR is manually configured using setupCCR from a terminal on which JAVA_HOME is pre-defined and if it points to an invalid location or JRE_HOME instead of a valid JDK_HOME, the command fails.

Workaround:

Unset JAVA_HOME and re-invoke setupCCR.

14.16 In Red Hat Enterprise Linux 5 Default Makefile Version does not Support Default DBNAME

The default Makefile version present in the RHEL5 machine is make 3.81. With this version, the default dbname is not recognized by those Oracle clients which are directly called from the Makefile.

Workaround:

You can use either of the following approaches:

• Use Makefile version 3.79

• Use @dbname whenever username/password is used in the Makefile

14.17 Oracle Clusterware Patching May Encounter Write Errors

When applying the 10.2.0.4 Oracle Clusterware patch set on Linux 32 platforms, under certain circumstances, the following error may occur:

Error in writing to file 'Oracle_Home/jdk/jre/bin/java'

This may happen more frequently if you are running Oracle Clusterware version 10.2 in conjunction with Oracle9i Oracle Real Application (RAC) databases. If you encounter this error, you need to shutdown the GSD on each node of the cluster and then proceed with the installation. Shutting down the GSD will have no impact on any running database instances on the cluster. To do this, perform the following steps (all steps can be performed from a single node):

1. Set the ORACLE_HOME environment variable to the Oracle Clusterware home.

2. Issue the following command to get the list of nodes in the cluster:

   $ORACLE_HOME/bin/olsnodes
   

3. Issue the following command, once for each node in the cluster:

   $ORACLE_HOME/bin/crs_stop ora.nodename.gsd
   

This procedure will shut down the GSD on each node of the cluster without shutting down the rest of the Oracle Clusterware stack, or affecting any of the running database instances on the cluster. Once this is done, proceed with the Oracle Clusterware patchset installation as usual.

Example:

Suppose you are patching a 2 node cluster with node names host1 and host2. The procedure you need to follow is the following:

1. Log in to host1.

2. Set the ORACLE_HOME environment variable to your CRS Oracle Home.

3. Run $ORACLE_HOME/bin/olsnodes. This command will return:

   host1

   host2

4. For each node returned by olsnodes, run the command to stop the GSD. In this example one would need to run 2 different commands (all from host1):

   $ORACLE_HOME/bin/crs_stop ora.host1.gsd
   $ORACLE_HOME/bin/crs_stop ora.host2.gsd