How to Apply Critical Patch Update (CPU) on RAC
Note: Before continue the following step please read the README file from the patch. Critical patch update (CPU) patches are cumulative, which means fixes from previous Oracle security alerts and critical patch updates are included. It is not required to have previous security patches applied before applying the CPUJul2011 patches. However, you must be on the stated patch set level for a given product home before applying the CPUJul2011 patches for that release.
The Critical Patch Update (CPU) patches are rolling up gradation, Do one of the following, depending on whether this is a RAC environment:
If this is a RAC environment, choose 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, Please refer to My Oracle Support Note 244241.1.
If this is not a RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating.
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.Find 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
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.1 Introduction 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.
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 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
2.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/
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;
4. 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.
Note: Before continue the following step please read the README file from the patch. Critical patch update (CPU) patches are cumulative, which means fixes from previous Oracle security alerts and critical patch updates are included. It is not required to have previous security patches applied before applying the CPUJul2011 patches. However, you must be on the stated patch set level for a given product home before applying the CPUJul2011 patches for that release.
The Critical Patch Update (CPU) patches are rolling up gradation, Do one of the following, depending on whether this is a RAC environment:
If this is a RAC environment, choose 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, Please refer to My Oracle Support Note 244241.1.
If this is not a RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating.
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.Find 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
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.1 Introduction 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.
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 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
2.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/
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;
4. 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.
No comments:
Post a Comment