Search

Join this Blog for direct reference of any post into your inbox. To join just click on "Join this Site" under "Follower" then Login with your Email.*** DECLARATION: I Maintain this Blog for Helping Myself While at Work and Welcome any body Needing Help!!!.*** CAUTION: Using any of the script from this Blog may contain at Own Risk. These scripts May or May not have been Tested.***

Wednesday, 27 March 2013

How to Apply Critical Patch Update (CPU) on RAC

Patch Details: Patch “CPUJULY2012”
CPU patch is released 4 times in a year JAN/APR/JUL/OCT
Version & Platform: 10.2.0.4 Database on LINUX

Overview: A Critical patch update (CPU) is a collection of patches for multiple security vulnerabilities. CPU patch are usually cumulative, which means fixes from previous Oracle security alerts and critical patch updates are included in current patch. However each advisory describes only the security fixes added since the critical patch update advisory. Thus it is not required to have previous security patches applied before applying the latest patches. However, you must be on the stated patch set level for a given product home before applying the latest patches for that release: Information about latest CPU patch
Note: Do not forget to read the README file from the patch before start the actual work.
        If this is a RAC environment, select one of the patch installation methods provided by OPatch (rolling, all node, or minimum downtime), and shutdown instances and listeners as appropriate for the installation method selected. This CPU patch is rolling RAC installable.
        If this is not a RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating.
Repeat the Steps for each node of RAC
– Shutdown the Oracle instances and services or listener on node 1
– Apply the patch to the on node 1
– Start the Oracle instance of node 1
– Now Shutdown the Oracle instance on node 2
– Apply the patch to on node 2
– Start the Oracle instance of node 2
– Repeat this process as per the number of node. 
1. Download the CPU required patchset from Metalink
2. Change the owner of the patch file to oracle user.
# chown –R oracle
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 “patchfile.zip”
5. Find and invoke the Opatch version
$ opatch version
OPatch Version: 10.2.0.4.2
$ opatch lsinventory
If you want check the CPU patch is whether rolling support or not, go to the patch directory
Cd /oracle/??  --patch directory
[oracle@rac1 ??]$ opatch query -all
6. Backup the oraInventory and Opatch directory
$cp -R oraInventory old_oraInventory
$cp -R opatch old_opatch
7. If you are Applying on RAC: Stop Instance/asm/nodeapps of node1
$ srvctl stop instance -d racdb –i racdb1
$ srvctl stop asm -n rac1
$ srvctl stop nodeapps -n rac1
8. Go to the Patch Directory and invoke opatch apply.
$ cd ??  --patch directory
$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 steps 7 to 9 for Node2
11. Verify Patches are applied 
          $opatch lsinventory -detail -oh $ORACLE_HOME
12. Start the Instance/Asm/Nodeapps of node2
$srvctl start instance –d racdb –i racdb2
$srvctl start asm –n rac2
$srvctl start nodeapps –n rac2
$crs_stat –t 
Post CPU Patch 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:
On node1/node2:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql cpu apply
SQL> @utlrp.sql
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series CPU. Check the following log files for any errors:
catbundle_CPU__APPLY_.log, catbundle_CPU__GENERATE_.log on the path $ORACLE_HOME/cfgtoollogs/catbundle
Recompiling Views in the Database
If you already applied this during previous CPU installation then you can skip this section. To check whether view recompilation has already been performed:
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 for RAC environment:
1. Run the pre-check script, 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_jan2010cpu.sql
Note: If the database is in RAC environment then perform both the steps otherwise (single instance db), perform only step1 skip the step 2.
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP UPGRADE;
SQL> @view_recompile_jan2010cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP;
2. 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:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql
Then, manually recompile any invalid objects:
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

1 comments: