<<Back to Oracle RAC Main Page
Step by Step Instruction to Patch Oracle RAC Cluster Version 11.2.0.4
Step0: download and read the readme.txt for the patch. The installation instruction and rollback instruction is provided in readme file.Here is the extract and simplified version of Oracle RAC patching procedure
Step1: Ensure the Latest OPatch utility is Available
- Check Current OPatch Utility Version
$export ORACLE_HOME=/ora_app/product/11.2.0.4/dbhome_1
$export PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch
$opatch version
OPatch Version: 11.2.0.3.6
OPatch succeeded.
- Upgrade OPatch Utility to The Latest Version
Latest OPatch utility for your version is available for Download from My Oracle Support patch 6880880.
To Upgrade the OPatch follow below steps for each OH and GI homes
- Download and transfer the OPatch utility file to all the server (I copied it in /u01/ora_app/stage)
- $unzip /u01/ora_app/stage/p6880880_112000_Linux-x86-64.zip
- $mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_Backup
- $ cp /u01/ora_app/stage/
OPatch $ORACLE_HOME/ - $ opatch versionOPatch Version: 11.2.0.3.21
OPatch succeeded.
Step2: Perform Complete Cluster Stack HealthCheck: Strongly Recommended
- Download latest ORACheck utility, install it and run it to perform the health check
- You can find the instruction guide, download package etc at MOS Note 1268927.2
- If you have latest version of TFA installed and configured ORACheck is part of TFA and already installed in your environment.
- You can run racheck directly from tfa CLI interface as below
$tfactl
tfactl> orachk - CRS stack is running and CRS_HOME is not set. Do you want to set CRS_HOME to /u01/grid/product/11.2.0.4/gi?[y/n][y]
- Follow the screen instruction to and wait for completion of ORACheck execution.
- Analyze the output file and fix any possible errors before proceeding to next step
Step3: Patch One node after another in Rolling fashion
- Verify the Database Services Running on Node1
$srvctl status service -d DB1
Service srv1 is running on instance(s) DB11,DB12
$srvctl status service -d DB2
Service srv2 is running on instance(s) DB21,DB22
Service srv1 is running on instance(s) DB11,DB12
$srvctl status service -d DB2
Service srv2 is running on instance(s) DB21,DB22
- Stop or relocate the services from the node1 to node2
NOTE: In production environment run this step at least few hours before starting the patching to ensure that all the sessions are properly gone from node1
In my case, since the services are running on all the nodes I will simply stop them on node1 (the node which I am going to patch first)
$srvctl stop service -d DB1 -s srv1 -n node1
$srvctl stop service -d DB2 -s srv2 -n node1
$srvctl stop service -d DB2 -s srv2 -n node1
- Verify and Confirm that All the Services are now running on 2nd node and no service is running on node1
$srvctl status service -d DB1
Service srv1 is running on instance(s) DB21
$srvctl status service -d DB2
$srvctl status service -d DB2
Service srv2 is running on instance(s) DB22
- Verify and Ensure that there is no Active Session and Transactions Running on Node1
$ sqlplus "/as sysdba"
SQL> select SID,USERNAME,STATUS from v$session where username not in ('SYS','DBSNMP');
no rows selected
SQL>col machine for a30
SQL>col username for a30
SQL>col program for a30 trun
SQL>col sid for 99999
SQL>set lines 300
SQL>col username for a30
SQL>col program for a30 trun
SQL>col sid for 99999
SQL>set lines 300
SQL>select sid,USED_UBLK,username,program,machine,systimestamp
SQL>from v$transaction t, v$session s
SQL>where SES_ADDR = s.saddr order by 1;
SQL>from v$transaction t, v$session s
SQL>where SES_ADDR = s.saddr order by 1;
no rows selected
SQL>select sid,USED_UBLK,username,program,machine,systimestamp
SQL>from gv$transaction t, gv$session s
SQL>where SES_ADDR = s.saddr order by 1;
SQL>from gv$transaction t, gv$session s
SQL>where SES_ADDR = s.saddr order by 1;
no rows selected
Step4: Create OCM response file
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output
/u01/ora_app/stage/ocm/ocm.rsp
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:
/u01/ora_app/stage/ocm/ocm.rsp
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:
You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: y
The OCM configuration response file (/u01/ora_app/stage/ocm/ocm.rsp) was successfully created.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: y
The OCM configuration response file (/u01/ora_app/stage/ocm
Step5: Run Opatch lsinventory for All homes and for All Patches
$opatch lsinventory -detail -oh /u01/grid/product/11.2.0.4/gi > /u01/ora_app/stage/CRS_HOME_Opatch_detail
$opatch lsinventory -detail -oh /ora_app/product/11.2.0.4/dbhome_1 > /u01/ora_app/stage/DB_HOME_Opatch_detail
$opatch lsinventory -detail -oh /ora_app/product/11.2.0.4/dbhome_1 > /u01/ora_app/stage/DB_HOME_Opatch_detail
Step6: Download and transfer the PSU to the server and unzip the patch file
Step7: Verify and resolve the Patch Conflicts
$opatch prereq CheckConflictAgainstOHWithDetail -oh /u01/grid/product/11.2.0.4/gi -ph ./
Oracle Interim Patch Installer version 11.2.0.3.21
Copyright (c) 2019, Oracle Corporation. All rights reserved.
Oracle Interim Patch Installer version 11.2.0.3.21
Copyright (c) 2019, Oracle Corporation. All rights reserved.
PREREQ session
Oracle Home : /u01/grid/product/11.2.0.4/gi
Central Inventory : /u01/oraInventory
from : /u01/grid/product/11.2.0.4/gi/oraInst.loc
OPatch version : 11.2.0.3.21
OUI version : 11.2.0.4.0
Log file location : /u01/grid/product/11.2.0.4/gi/cfgtoollogs/opatch/opatch2019-08-22_09-43-17AM_1.log
Central Inventory : /u01/oraInventory
from : /u01/grid/product/11.2.0.4/gi/oraInst.loc
OPatch version : 11.2.0.3.21
OUI version : 11.2.0.4.0
Log file location : /u01/grid/product/11.2.0.4/gi/cfgtoollogs/opatch/opatch2019-08-22_09-43-17AM_1.log
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
NOTE: The Patching Steps are only valid for systems where GI Home and the Database Homes are not shared and ACFS file system is not configured
Step8: As root user, execute the following command on node1
for GI Home
#opatch auto /u01/ora_app/stage/29698727 -och /u01/grid/product/11.2.0.4/gi -ocmrf /u01/ora_app/stage/ocm/ocm.rsp
#opatch auto /u01/ora_app/stage/29698727 -och /u01/grid/product/11.2.0.4/gi -ocmrf /u01/ora_app/stage/ocm/ocm.rsp
For DB Home
#opatch auto /u01/ora_app/stage/29698727 -oh /ora_app/product/11.2.0.4/dbhome_1 -ocmrf /u01/ora_app/stage/ocm/ocm.rsp
#opatch auto /u01/ora_app/stage/29698727 -oh /ora_app/product/11.2.0.4/dbhome_1 -ocmrf /u01/ora_app/stage/ocm/ocm.rsp
NOTE: I prefer patching each OH separately to avoid any issue. You can patch all the homes in one go using command
#opatch auto /u01/ora_app/stage/29698727 -ocmrf /ora_work/patch/ocm/ocm.rsp
Step9: Repeat step 3 to 8 for node2.
Note: ensure to adjust the node name and other node specific details accordingly
Step10: Load modified SQL files into the database
Once all the nodes are patched, follow the steps to load modified SQL files into the database. For an Oracle RAC environment, perform these steps on only one node.
$cd $ORACLE_HOME/rdbms/admin
sqlplus "/as sysdba"
SQL>@catbundle.sql psu apply
SQL>@utlrp.sql
SQL>set line 200
SQL>col ACTION_TIME for a30
SQL>col COMMENTS for a30
SQL>col ACTION for a15
SQL>select name from v$database;
SQL>select * from dba_registry_history;
SQL>col COMP_NAME for a50 ;
SQL>col STATUS for a20
SQL>select COMP_NAME,VERSION,STATUS,MODIFIED from dba_registry order by MODIFIED;
SQL>col STATUS for a20
SQL>select COMP_NAME,VERSION,STATUS,MODIFIED from dba_registry order by MODIFIED;
Hi Sir,
ReplyDeleteThank you for sharing this. just a newbie question here, I noticed that you did not stop the database and listener and the grid infrastructure on the node to be patched. Is it automatically done by the opatch auto? Can you please also confirm that the other node is not affected and still open for users? Thank you very much
If using opatchauto shutdown and start is taken care by opatch auto utility itself . Clusterware stack must be up and running to use opatch auto. by default the local node is affected. So its the server where you execute the opatch auto
Delete