Patch 9352164 – 10.2.0.4.4 Patch Set Update

2.3.1.1 Environment Checks

1. Ensure that the $PATH definition has the following executables: make, ar, ld, and nm.

   The location of these executables depends on your operating system. On many operating systems, they are located in /usr/ccs/bin, in which case you can set your PATH definition as follows:

   export PATH=$PATH:/usr/ccs/bin  

2.3.1.2 “spare” Parameters and One-off Patches

If you have any one-off patches installed in the Database home, you must check whether any “spare” parameters (_first_spare_parameter, _second_spare_parameter, and so on) are set in the init.ora file before installing the 10.2.0.4.4 PSU. Failure to do so could result in memory corruption.

• If no “spare” parameters are set, or the only one set is _first_spare_parameter for bug 7291739, then no other action is required.

• Otherwise, you must follow additional steps (explained in Section 2.3.2, “Patch Installation Instructions”) during the patch installation, including explicit rollback of the conflicting patch that includes “spare” parameter changes.

To check if any “spare” parameters are set, enter the following statements:

sqlplus  SQL> CONNECT / AS SYSDBA  SQL> show parameter spare  

2.3.1.3 One-off Patch Conflict Detection and Resolution

For an introduction to the PSU one-off patch concepts, see “Patch Set Updates Patch Conflict Resolution” in My Oracle Support Note 854428.1 Patch Set Updates for Oracle Products.

The fastest and easiest way to determine whether you have one-off patches in the Oracle home that conflict with the PSU, and to get the necessary conflict resolution patches, is to use the Patch Recommendations and Patch Plans features on the Patches & Updates tab in My Oracle Support. These features work in conjunction with the My Oracle Support Configuration Manager. Recorded training sessions on these features can be found in Note 603505.1.

However, if you are not using My Oracle Support Patch Plans, follow these steps:

1. Determine whether any currently installed one-off patches conflict with the PSU patch as follows:

   unzip p9352164_10204_<platform>.zip  opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./9352164  

2. The report will indicate the patches that conflict with PSU 9352164 and the patches for which PSU 9352164 is a superset. Refer to “Patch Set Updates Patch Conflict Resolution” in My Oracle Support Note 854428.1 Patch Set Updates for Oracle Products.

   Note that Oracle proactively provides 10.2.0.4.3 one-off patches for common conflicts.

3. Use My Oracle Support Note 1061295.1 Patch Set Updates – One-off Patch Conflict Resolution to determine, for each conflicting patch, whether a conflict resolution patch is already available, and if you need to request a new conflict resolution patch or if the conflict may be ignored

4. When all the 10.2.0.4.4 one-off patches that you have requested are available at My Oracle Support, proceed with Section 2.3.2, “Patch Installation Instructions”.

2.3.3.1 Applying Conflict Resolution Patches

Apply the patch conflict resolution one-off patches that were determined to be needed when you performed the steps in Section 2.3.1.3, “One-off Patch Conflict Detection and Resolution”.

2.3.3.2 Loading Modified SQL Files into the Database

The following steps load modified SQL files into the database. For a RAC environment, perform these steps on only one node.

1. For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:

   cd $ORACLE_HOME/rdbms/admin  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> STARTUP  SQL> @catbundle.sql psu apply  SQL> -- Execute the next statement only if this is the first 10.2.0.4 PSU applied in the Oracle home.  SQL> @utlrp.sql  SQL> QUIT  

   For information about the catbundle.sql script, see My Oracle Support Note 605795.1 Introduction to Oracle Database catbundle.sql.

2. Check the following log files in $ORACLE_HOME/cfgtoollogs/catbundle for any errors:

   catbundle_PSU_<database SID>_APPLY_<TIMESTAMP>.log  catbundle_PSU_<database SID>_GENERATE_<TIMESTAMP>.log  

   where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are errors, refer to Section 3, “Known Issues”.

2.3.3.3 Optional: Configuring for Undo Retention (Bug 7291739)

The PSU includes the fix for bug 7291739, which allows you to specify the high threshold undo retention by setting _first_spare_parameter. The tuned value of undo retention will then not exceed the parameter’s value. This underscore parameter is a dynamic parameter, and its value can be changed with “alter system set “_first_spare_parameter”=<new_value>;”.

Additional information is available in My Oracle Support Note 742035.1 Contention Under Auto-Tuned Undo Retention.

2.3.3.4 Recompiling Views in the Database

Recompiling views in the database is a one-time action that is required to complete the installation of CPU fixes that were initially released in January, 2008. It requires that the database be in upgrade mode, so this step is not rolling RAC installable. You may defer this step to a later downtime. If you do this, your system will continue to work; however, the installation of the January 2008 CPU fixes will not be complete until the view recompilation is completed.

Skip this section if you have recompiled views for this database during the installation of a previous PSU or CPU.

The time required to recompile the views and related objects depends on the total number of objects and on your system configuration. In one internal Oracle test with approximately 2000 views and 4000 objects, the total execution time for view_recompile_jan2008cpu.sql and utlrp.sql was about 30 minutes.

If you want to check whether view recompilation has already been performed for the database, execute the following statement:

SELECT * FROM registry$history where ID = '6452863';  

If the view recompilation has been performed, this statement returns one or more rows. If the view recompilation has not been performed, this statement returns no rows.

The following steps recompile the views in the database. For a RAC environment, perform these steps on only one node.

1. Run the pre-check script (so named because it was initially released in CPUJan2008), which reports the maximum number of views and objects that may be recompiled:

   cd $ORACLE_HOME/cpu/view_recompile  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> @recompile_precheck_jan2008cpu.sql  SQL> QUIT  

   The purpose of this step is to help you determine whether view recompilation should be done at the same time as the PSU install, or scheduled later.

2. If the database is not in a RAC environment, perform this step and skip the next step. (If the database is in a RAC environment, go to the next step.)

   Run the view recompilation script. Note that this script is run with the database in upgrade mode, which restricts connections as SYSDBA.

   cd $ORACLE_HOME/cpu/view_recompile  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> SHUTDOWN IMMEDIATE  SQL> STARTUP UPGRADE  SQL> @view_recompile_jan2008cpu.sql  SQL> SHUTDOWN;  SQL> STARTUP;  SQL> QUIT  

3. If the database is in a RAC environment, run the view recompilation script as follows. Note that this script is run with the database in upgrade mode, which restricts connections as SYSDBA. Stop all instances except the one where the view recompilation is being executed.

   cd $ORACLE_HOME/cpu/view_recompile  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> STARTUP NOMOUNT  SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;  SQL> SHUTDOWN  SQL> STARTUP UPGRADE  SQL> @view_recompile_jan2008cpu.sql  SQL> SHUTDOWN;  SQL> STARTUP NOMOUNT;    Set the CLUSTER_DATABASE initialization parameter to TRUE:    SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile;    Restart the database:    SQL> QUIT  cd $CRS_HOME/bin  srvctl start database -d <database-name>  

4. Check the log file for any errors. The log file is in the current directory and is named: vcomp_<sid>_<timestamp>.log

5. If any invalid objects were reported, run the utlrp.sql script as follows:

   cd $ORACLE_HOME/rdbms/admin  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> @utlrp.sql  

   Then, manually recompile any invalid objects. For example:

   SQL> alter package schemaname.packagename compile;