CpuJanuary06 < PSSGroup

WARNING: This web is not used anymore. Please use PDBService.CpuJanuary06 instead!

TWiki>

PSSGroup Web>PhysicsDatabasesSection>DbaArea>CpuJanuary06 (2006-03-01, LucaCanali)

EditAttachPDF

Contents:

Oracle CPU patch January 2006 installation instructions
RAC 10gR1 (10.1.0.4)
RAC 10gR2 addendum (10.2.0.1)
10g (10.1.0.4)
9i (9.2.0.7)

Oracle CPU patch January 2006 installation instructions

This Wiki page has the scope of documenting the installation steps for the Oracle security patch CPUJAN2006 for the database servers at PSS.

Database Oracle Homes needs to be patched (all versions) as documented in Metalink's Note 343382.1 . A third-party link with a description of the vulnerabilities: http://www.red-database-security.com/advisory/oracle_cpu_jan_2006.html

The following Oracle home types are not affected by this CPU patched:

Oracle CRS
Oracle Agent
Oracle Client (there are 3 vulnerabilities for Oracle clients, but not relevant for our environment)

Note: Since Jan 20th the patchinstallation guide reports that CPU Jan06 patch is rolling installable for 10.1.0.4 and 10.2.0.1. The instructions here below refer to the previous indication were the patch was marked as non-rolling installable. Minor changes are needed for the rolling installation procedure.

Additional configurations steps are documented below. These steps require instance shutdown and therefore have been 'queued in' this maintenance window for CPUJAN06.

Patching schedule and DB List: ScheduleCPUJan2006

RAC 10gR1 (10.1.0.4)

Note: These are pre-install steps that should be done just before the maintenance window starts

If you want to copy-paste commands from this manual set properly the following environment variables (on both nodes):

     export RAC_DB_NAME=<name_of_the_database> (e.g. int2r)
     export RAC_INST_1=<first_RAC_instance>    (e.g. int2r1)
     export RAC_INST_2=<second_RAC_instance>   (e.g. int2r2)
     export RAC_NODE_1=<first_RAC_node>        (e.g. itrac05)
     export RAC_NODE_2=<second_RAC_node>       (e.g. itrac06)

Copy the patch to all cluster nodes:

     cd $HOME/oracle_binaries
     scp oracle@itrac05:~/oracle_binaries/p4751928_10104_LINUX.zip .
     $ORACLE_HOME/bin/unzip ./p4751928_10104_LINUX.zip

Copy the new version of OPatch to all cluster nodes and use it to replace the old OPatch:

     scp oracle@itrac05:~/oracle_binaries/p2617419_10102_GENERIC.zip .

     $ORACLE_HOME/bin/unzip ./p2617419_10102_GENERIC.zip 
     cd $ORACLE_HOME
     tar cvvf OPatch.tar OPatch
     rm -rf OPatch
     mv $HOME/oracle_binaries/OPatch .
     $ORACLE_HOME/OPatch/opatch lsinventory

Note: command above should complete successfully and it should show that OPatch version 10.0.0.0.54 is being used.

Additional configuration steps

From one of the cluster nodes connect to the database and change value of the CLUSTER_DATABASE_INSTANCES parameter:

     sqlsys_DB
     SQL> ALTER SYSTEM SET CLUSTER_DATABASE_INSTANCES=4 SCOPE=spfile SID='*';
     SQL> exit

     sqlsys_ASM
     SQL> ALTER SYSTEM SET CLUSTER_DATABASE_INSTANCES=4 SCOPE=spfile SID='*';
     SQL> exit

Change the audit_file_destination to the /ORA/dbs00 filesystem:

     mkdir /ORA/dbs00/oracle/admin/$RAC_DB_NAME/adump
    (REPEAT for both RAC nodes)

     sqlsys_DB
     SQL> ALTER SYSTEM SET audit_file_dest='/ORA/dbs00/oracle/admin/EDIT_THIS_PART/adump' SCOPE=spfile SID='*';
     SQL> exit
     NOTE: change audit_file_dest only for the db instance, NOT the asm instance

Configure the dump directories to use the correct filesystem (/ORA/dbs00) when not already so. (Check the DB and the ASM instances).

Sample code:

  mkdir /ORA/dbs00/oracle/admin/DBNAMEHERE/bdump
  alter system set background_dump_dest='/ORA/dbs00/oracle/admin/DBNAMEHERE/bdump' scope=spfile;
  mv /ORA/dbs01/oracle/admin/DBNAMEHERE/bdump /ORA/dbs01/oracle/admin/DBNAMEHERE/OLD_bdump

  mkdir /ORA/dbs00/oracle/admin/DBNAMEHERE/udump
  alter system set user_dump_dest='/ORA/dbs00/oracle/admin/DBNAMEHERE/udump' scope=spfile;
  mv /ORA/dbs01/oracle/admin/DBNAMEHERE/udump /ORA/dbs01/oracle/admin/DBNAMEHERE/OLD_udump

  mkdir /ORA/dbs00/oracle/admin/DBNAMEHERE/cdump
  alter system set core_dump_dest='/ORA/dbs00/oracle/admin/DBNAMEHERE/cdump' scope=spfile;
  mv /ORA/dbs01/oracle/admin/DBNAMEHERE/cdump /ORA/dbs01/oracle/admin/DBNAMEHERE/OLD_cdump

  mkdir /ORA/dbs00/oracle/admin/DBNAMEHERE/adump
  alter system set audit_file_dest='/ORA/dbs00/oracle/admin/DBNAMEHERE/adump' scope=spfile;
  mv /ORA/dbs01/oracle/admin/DBNAMEHERE/adump /ORA/dbs01/oracle/admin/DBNAMEHERE/OLD_adump

 Note 1: Similar settings for the ASM instance (audit_file_dest ONLY on the DB instance)
 Note 2: Directory and filesystem changes have to be applied to all RAC nodes

ASM instance memory allocation

     sqlsys_ASM
     SQL> alter system set shared_pool_size=64m scope=spfile sid='*';
     SQL> alter system set large_pool_size=40m scope=spfile sid='*';
     SQL> exit

ASM instance memory (other option, as they are dynamic). From each instance:

     sqlsys_ASM
     SQL> alter system set shared_pool_size=64m scope=both sid='+ASM1';
     SQL> alter system set large_pool_size=40m scope=both sid='+ASM1';
     SQL> exit

ATLAS ONLY: set the service_names parameter to null (it's supposed to be handled dynamically by CRS):

     sqlsys_DB
     SQL> alter system reset service_names scope=spfile sid='*';
     SQL> exit

NOTE: Service downtime starts here

From one of the cluster nodes shutdown the database, ASM instances and node applications:

     srvctl stop database -d $RAC_DB_NAME
     srvctl stop asm -n $RAC_NODE_1
     srvctl stop asm -n $RAC_NODE_2
     srvctl stop nodeapps -n $RAC_NODE_1
     srvctl stop nodeapps -n $RAC_NODE_2

Check whether everything is really stopped:
```
     crsstat.sh
   
```

Go to each node of the cluster and apply the patch:
```
     cd $HOME/oracle_binaries/4751928
     $ORACLE_HOME/OPatch/opatch apply -local
   
```
(Note a message asking to rollback Patch 4567866 will appear, answer Y)

Once the OPatch succeeds on both nodes startup node aplications, ASM instance and DB instance on one of the cluster nodes and from this node execute patch post-installation steps:

     srvctl start nodeapps -n $RAC_NODE_1
     srvctl start asm -n $RAC_NODE_1
     srvctl start instance -d $RAC_DB_NAME -i $RAC_INST_1

     crsstat.sh

     cd $ORACLE_HOME/cpu/CPUJan2006
     sqlsys_DB
     SQL> select count(*) from dba_objects where status='INVALID';
     SQL> @catcpu.sql
     SQL> @?/rdbms/admin/utlrp.sql
     SQL> select count(*) from dba_objects where status='INVALID';
     SQL> exit

Review the log created in the $ORACLE_HOME/cpu/CPUJan2006 directory

Startup the rest of the RAC:

     srvctl start nodeapps -n $RAC_NODE_2
     srvctl start asm -n $RAC_NODE_2
     srvctl start instance -d $RAC_DB_NAME -i $RAC_INST_2

     crsstat.sh

     srvctl start service -d $RAC_DB_NAME

     crsstat.sh

RAC 10gR2 addendum (10.2.0.1)

Same patch installation instructions as for 10gR1 apply here with the additions:

the patchset is rolling (tested successfully, but only on a test DB with no users)
10.2.0.1-specific binaries are required both for the patchset and the opatch utility (see metalink for details)
- CPUpatch: 4751931 (version from 20th Jan)
- Opatch version: 10.2.0.1.1

Note: on January 20th Oracle released a 2nd version of this patch. Oracle homes patched with the previous version need to be repatched.

10g (10.1.0.4)

Note: These are pre-install steps that should be done just before the maintenance window starts

Make sure you have Perl 5.00503 (or later)
```
   perl -v
   
```

You must use OPatch version 1.0.0.0.54 or later.

Check the current version:

   $ORACLE_HOME/OPatch/opatch version

If not, install it. To the $ORACLE_HOME directory copy the p2617419_10102_GENERIC.zip and unzip it:

   cp p2617419_10102_GENERIC.zip $ORACLE_HOME/
   mv $ORACLE_HOME/OPatch/ $ORACLE_HOME/OPatch.bak
   cd $ORACLE_HOME
   unzip p2617419_10102_GENERIC.zip

Check again the current version and if it works:

   $ORACLE_HOME/OPatch/opatch lsinventory

Before starting the installation check whether "java" and "jar" executables are present in your Oracle Home. In a standard Oracle installation, "java" is available in $ORACLE_HOME/jre//bin directory and "jar" is available in $ORACLE_HOME/jdk/bin directory.

   ls -l $ORACLE_HOME/jre/<JDKversion>/bin
   ls -l $ORACLE_HOME/jdk/bin

If you don't have a standard installation and these commands are not present, then invoke the "opatch apply" command with the -jdk flag, specifying the full path to the JDK to be used.

Check if the following executables must be present in the $PATH: make, ar, ld, and nm.

Copy the p4751928_10104_LINUX.zip file to your oracle's home directory, unzip it there and go to the 4751928 subdircetory.

   unzip p4751928_10104_LINUX.zip
   cd ~/4751928

NOTE: Service downtime starts here

Shutdown all instances and listeners associated to the ORACLE_HOME being updated:

   lsnrctl stop
   sqlplus "/ as sysdba";
   SQL>  shutdown immediate;
   SQL>  exit;

Apply the CPU:

   $ORACLE_HOME/OPatch/opatch apply

   If you encounter any errors, please refer to the "Known issues" section of the 343384.1 document.

Start up all database instances running out of the ORACLE_HOME being patched and run a postinstallation script.

   cd $ORACLE_HOME/cpu/CPUJan2006
   sqlplus "/ as sysdba";
   SQL> startup;
   SQL> @catcpu.sql;
   SQL> exit;

Examin the log file. If you encounter any errors, please refer to the "Known issues" section of the 343384.1 document.

If catcpu.sql reports any Invalid Objects, compile the invalid objects using the following:

   cd $ORACLE_HOME/rdbms/admin
   sqlplus "/ as sysdba";
   SQL> @utlrp.sql

Check again if invalid objects exist:

   SQL> select OBJECT_NAME from DBA_OBJECTS where status = 'INVALID';
   SQL> exit;

Start the listener:
```
   lsnrctl start
   
```

9i (9.2.0.7)

Note: These are pre-install steps that should be done just before the maintenance window starts

Make sure you have Perl 5.00503 (or later)
```
   perl -v
   
```

You must use OPatch version 1.0.0.0.54 or later.

Check the current version:

   $ORACLE_HOME/OPatch/opatch version

If not, install it. To the $ORACLE_HOME directory copy the p2617419_10102_GENERIC.zip and unzip it:

   cp p2617419_10102_GENERIC.zip $ORACLE_HOME/
   mv $ORACLE_HOME/OPatch/ $ORACLE_HOME/OPatch.bak
   cd $ORACLE_HOME
   unzip p2617419_10102_GENERIC.zip

Check again the current version and if it works:

   $ORACLE_HOME/OPatch/opatch lsinventory

Before starting the installation check whether "java" and "jar" executables are present in your Oracle Home. In a standard Oracle installation, "java" is available in $ORACLE_HOME/jre//bin directory and "jar" is available in $ORACLE_HOME/jdk/bin directory.

   ls -l $ORACLE_HOME/jre/<JDKversion>/bin
   ls -l $ORACLE_HOME/jdk/bin

If you don't have a standard installation and these commands are not present, then invoke the "opatch apply" command with the -jdk flag, specifying the full path to the JDK to be used.

Check if the following executables must be present in the $PATH: make, ar, ld, and nm.

Copy the p4751923_92070_LINUX.zip file to your oracle's home directory, unzip it there and go to the 4751923 subdircetory.

   unzip p4751923_92070_LINUX.zip
   cd ~/4751923

NOTE: Service downtime starts here

Shutdown all instances and listeners associated to the ORACLE_HOME being updated:

   lsnrctl stop
   sqlplus "/ as sysdba";
   SQL>  shutdown immediate;
   SQL>  exit;

Apply the CPU:

   $ORACLE_HOME/OPatch/opatch apply

   If you encounter any errors, please refer to the "Known issues" section of the 343384.1 document.

Start up all database instances running out of the ORACLE_HOME being patched and run a postinstallation script.

   cd $ORACLE_HOME/cpu/CPUJan2006
   sqlplus "/ as sysdba";
   SQL> startup;
   SQL> select OBJECT_NAME from DBA_OBJECTS where status = 'INVALID';
   SQL> @catcpu.sql;
   SQL> exit;

Examin the log file. If you encounter any errors, please refer to the "Known issues" section of the 343384.1 document.

If catcpu.sql reports any Invalid Objects, compile the invalid objects using the following:

   cd $ORACLE_HOME/rdbms/admin
   sqlplus "/ as sysdba";
   SQL> @utlrp.sql

Check again if invalid objects exist:

   SQL> select OBJECT_NAME from DBA_OBJECTS where status = 'INVALID';
   SQL> exit;

Start the listener:
```
   lsnrctl start
   
```

Topic revision: r16 - 2006-03-01 - LucaCanali

PSSGroup

PSSGroup

On Shift

PSSGroup Wiki
Last Changes
Pages Index
Search web

- Cern Search
- TWiki Search
- Google Search
PSSGroup All webs

Copyright &© 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback