How to apply cpu patch in oracle 11gr2 RAC

What is CPU Patch?


Critical patch update (CPU) patches are cumulative, which means fixes from previous Oracle security alerts and critical patch updates are included.
A Critical Patch Update is a collection of patches for multiple security vulnerabilities. Critical Patch Update patches are usually cumulative but each advisory describes only the security fixes added since the previous Critical Patch Update advisory. Thus, prior Critical Patch Update advisories should be reviewed for information regarding earlier published security fixes.

When is CPU Patches Released?

CPU patches is released 4 times a year.
January, April, July &October.

Information about the latest CPU Patch can be found in the below link

Note: To download the latest CPU patch, one must have a valid oracle support login.

Steps to Apply CPU

Pre-Installation: 
Shutdown all the instance , and oracle services such as listener. 
ensure $PATH variable.
Download Patchand unzip it.
Use the Opatch like this : opatch napply -skip_subset -skip_duplicate.
Startup databas.

Post-Installation :

 cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SQL> @catbundle.sql cpu apply

***************************************************************************
How to apply it in a RAC Environment?

Applies to:

Operating System – RHEL/OEL 5.8

Oracle Version(s) – 11.2.0.1

Note: Before continue the following step please read the README file from the patch.

Step by step CPU patches Applying:


If you are wish to applying rolling CPU patch on RAC, then the following steps must be following.

Rolling patch (no downtime)
-Shutdown the Oracle instance on node 1
-Apply the patch to the RAC home on node 1
-Start the Oracle instance on node 1
-Shutdown the Oracle instance on node 2
-Apply the patch to the RAC home on node 2
-Start the Oracle instance on node 2
-Shutdown the Oracle instance on node 3
-Apply the patch to the RAC home on node 3
-Start the Oracle instance on node 3

1.Download the CPU patch p12419249_10204_Linux-x86 from Metalink.

2.Change the owner of the patch file to oracle user.
# chown –R oracle: install p12419249_10204_Linux-x86.zip

3.Set the PATH variable to locate the opatch utility.
$ export PATH=$PATH: $ORACLE_HOME/OPatch

4.unzip the patch and go the unzipped directory
$unzip p12419249_10204_Linux-x86.zip

5.Fine the Opatch version
$ opatch version
Invoking OPatch 10.2.0.4.2
OPatch Version: 10.2.0.4.2
$ opatch lsinventory
Note: if you want check the CPU patch is whether rolling support or not, follow the steps.
-go to the patch directory
Cd /oracle/12419249
[oracle@rac1 12419249]$ opatch query -all
Invoking OPatch 10.2.0.4.2
Oracle Interim Patch Installer version 10.2.0.4.2
Copyright (c) 2007, Oracle Corporation.  All rights reserved.
Oracle Home                  : /oracle/product/10.2.0/rdbms
Central Inventory           : /oracle/product/10.2.0/oraInventory
from                             : /etc/oraInst.loc
OPatch version               : 10.2.0.4.2
OUI version                    : 10.2.0.4.0
OUI location                   : /oracle/product/10.2.0/rdbms/oui
Log file location              : /oracle/product/10.2.0/rdbms/cfgtoollogs/opatch/opatch2011-05-01_08-55-20AM.log
-------------------------------------------------------------------------------- 
Patch created on 20 May 2011, 03:02:21 hrs PST8PDT
Need to shutdown Oracle instances: false      (<--hear false mean we no need to down the database)
 Patch is roll-backable: true
 Patch is a rolling patch: true
 Patch has sql related actions: false
 Patch is an online patch: false
 Patch is a portal patch: false
 List of platforms supported:
 46: Linux Intel
 List of bugs to be fixed:
 8534387: CPUJUL2009 DATABASE 10.2.0.4
 8290506: CPUAPR2009 DATABASE 10.2.0.4
 7375644: MLR BUG FOR 10.2.0.4 FOR CPUOCT2008
 9352191: CPUAPR2010 DATABASE 10.2.0.4
 9655017: CPUJUL2010 DATABASE 10.2.0.4
 7150470: MLR BUG FOR 10.2.0.4 FOR CPUJUL2008
 7592346: CPUJAN2009 DATABASE 10.2.0.4
 9952272: CPUOCT2010 DATABASE 10.2.0.4
 9119226: CPUJAN2010 DATABASE 10.2.0.4
 11725015: CPUAPR2011 DATABASE 10.2.0.4
 12419249: CPUJUL2011 DATABASE 10.2.0.4
 8836308: CPUOCT2009 DATABASE 10.2.0.4
 10249540: CPUJAN2011 DATABASE 10.2.0.4
 List of optional components:
 oracle.rdbms.rsf  :  10.2.0.4.0
 oracle.rdbms       :  10.2.0.4.0
6.Backup the oraInventory  and Opatch directory
$cp -R oraInventory old_oraInventory
$cp -R opatch old_opatch
7.If you are Applying on RAC, follow the below steps:
Shut down the instance one of node
$ srvctl stop instance -d racdb –i racdb1
Shut down the ASM instanc respected node
$ srvctl stop asm -n rac1
Shut down all Nodeapps services of the node
$ srvctl stop ndoeapps -n rac1
8.Go to the Patch Directory and invoke opatch apply.
$ cd 12419249
$opatch apply or $opatch napply -skip_subset -skip_duplicate
9.Verify Patches are applied
$opatch lsinventory -detail -oh $ORACLE_HOME
10.Now start the Node1 and repeat the same 1 to 10 steps on Node2
$ srvctl start nodeapps –n rac1
$srvctl start asm –n rac1
$srvctl start instance –d racdb –i racdb1
Note: if the database on rac1 located, now relocate to node2
crs_relocate ora.racdb.db
11.Now stop Instance,asm and nodeapps on node2
$ srvctl stop instance –d racdb –i racdb2
$ srvctl stop asm –n rac2
$ srvctl stop nodeapps –n rac2
12.Go to the Patch Direcotry and invoke the opatch apply on node2
$ cd 12419249
$ opatch apply or opatch napply -skip_subset -skip_duplicate 
     13.Verify Patches are applied 
          $opatch lsinventory -detail -oh $ORACLE_HOME
     14.Start  the Instance,Asm and Nodeapps on node2
$srvctl start instance –d racdb –i racdb2
$srvctl start asm –n rac2
$srvctl start nodeapps –n rac2
$crs_stat –t 

Post CPU installation Steps:

For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus on each node.

Connect as SYSDBA and run the catbundle.sql script as follows:
On node1 and node2:

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql cpu apply
SQL> @utlrp.sql
SQL> QUIT
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series CPU.
For information about the catbundle.sql script, see My Oracle Support Note 605795.1Introduction to Oracle Database catbundle.sql.
Check the following log files in $ORACLE_HOME/cfgtoollogs/catbundle for any errors:
catbundle_CPU__APPLY_.log
catbundle_CPU__GENERATE_.log

Recompiling Views in the Database
You may skip this section if you have recompiled views for this database during the installation of a previous 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. If no rows returns then go the following steps.
The following steps recompile the views in the database. For a RAC environment, perform these steps on only one node.

 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 CPU install, or scheduled later.
Note:
 If the database is not in a RAC environment(if Single Instance), perform this step and skip the next step 2. (If the database is in a RAC environment, go to the next step2.)
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

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> @?/ cpu/view_recompile /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 racdb
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;

 Verify Patches are applied.
$opatch lsinventory -detail -oh $CRS_HOME #if you have CRS_HOME
$opatch lsinventory -detail -oh $ORACLE_HOME #if you have both ORACLE_HOME

  The CPU patch was successfully applied.

*****************************END*************************************

No comments:

ORA-01552: cannot use system rollback segment for non-system tablespace 'TEMP'

 ORA-01552: cannot use system rollback segment for non-system tablespace "string" Cause: Used the system rollback segment for non...