How To Apply Patch On Rac Database

15.01.2020

5 Oracle Real Application Clusters PatchingAn Oracle Real Application Clusters (RAC) environment is one in which active instances can concurrently execute transactions on a shared database. Patching in an Oracle (RAC) environment is slightly different compared to patching a single node.Real Application Clusters can be patched in three different ways:.All Node Patching.Rolling Patching.Minimum Downtime PatchingThis chapter includes the following topics about patching Oracle RAC:.Specifying Node Names and Lists.All Node Patching.Rolling Patching.Minimum Downtime Patching. All Node PatchingIn All Node Patching, all Oracle RAC nodes are initially brought down and the patch is applied on all the nodes, then all the nodes are brought back up. This mode is normally used for very critical patches and it leads to maximum downtime. OPatch uses this mode as the default for patch applications unless specified otherwise.Figure 5–1 shows an example of All Node Patching. In this example, Systems A,B, and C are nodes in this Oracle RAC. When you perform an All Node Patching in this cluster, you bring down systems A,B, and C and apply patches to all of these nodes.

How To Apply Patch On Rac Database

You then bring up systems A,B, and C again. Rolling PatchingIn Rolling Patching, each node is shut down, the patch is applied, then each node is brought back up again. This is done node by node separately until all nodes in Oracle RAC are patched. This is the most efficient mode of applying an interim patch to an Oracle RAC setup because this results in no downtime. Only some patches can be applied in this mode.

The type is generally specified in the patch metadata.Figure 5–2 shows an example of Rolling Patching. In this example, systems A,B, and C are nodes in this Oracle RAC. When you perform a Rolling Patching in this cluster, you bring down system A, and apply a patch to it, then bring it back up.

You then do the same with systems B and C. The patch is thereby applied in a rolling fashion. The main advantage of this type of patching is that there is absolutely no downtime while applying patches because only one system is brought down at any given time. Minimum Downtime PatchingIn Minimum Downtime Patching, the nodes are divided into sets. Initially, the first set is shut down and the patch is applied to it.

Apply

How To Apply Patch File

After this, the second set is shut down. The first set is brought up and patch is applied to the second set. The second set is also brought up now. All the nodes in the Real Application Clusters are now patched. This mode leads to less downtime for the Real Application Clusters when both the sets are brought down. This mode is executed by using -minimizedowntime command line option. You can also activate this option from the response file.Figure 5–3 shows an example of Minimum Downtime Patching.

In this example, systems A,B, and C are nodes in this Oracle RAC. They are divided into two sets: set 1 contains systems A and B, and set 2 contains system C.

When you perform Minimum Downtime Patching in this cluster, you shut down set 1 and apply a patch to it. You then shut down set 2, bring up set 1, and apply a patch to set 2. After applying the patch, you bring up set 2 again. Now both sets 1 and 2 are patched.

Why would you want to 'not' use OPATCHAUTO? Maybe because there's no bash shell in your server due to some reason, or you just want to avoid any complications by opatchauto, or simply you like a more granular control over the patching process.I primarily work on Oracle RAC setups on HP-UX servers - where the bash shell is not installed (and cant be due to policy). You will agree, life is much easier on Linux. Therefore I must make use of the old and dependable 'opatch' utility!About the October 2016 patch:Patch File: p24420HPUX-IA64.zipContents: DB PSU patch #24006101 and OCW PSU patch #23854735The unzipped patch file path: /u01/software/psuoct2016/12cGI/24412235About the environment:- In the below example, I am applying the patch on a 2-node RAC in a rolling mode.

I will be sharing only the tested steps and not the outputs.- I usually have 4 putty sessions open on each node:. GRIDHOME environment variables set. RDBMSHOME environment variables set.

Monitoring the activity in the alert.log of the crs. Monitoring the activity in the alert.log of the database.

As Grid Infrastructure Owner (oracle), apply the OCW patch on the Grid Home: $GRIDHOME/OPatch/opatch napply -oh $GRIDHOME -local /u01/software/psuoct2016/12cGI/24447354. As Grid Infrastructure Owner (oracle), apply the DB PSU patch on the Grid Home:$GRIDHOME/OPatch/opatch napply -oh $GRIDHOME -local /u01/software/psuoct2016/12cGI/24461015. As RDBMS Owner (oracle), apply the OCW PSU patch on the RDBMS Home:$ cd /u01/software/psuoct2016/12cGI/2444735/custom/scripts$./prepatch.sh$ $ORACLEHOME/OPatch/opatch napply -oh $RDBMSHOME -local /u01/software/psuoct2016/12cGI/24447356. As RDBMS Owner (oracle), apply the DB PSU patch on the RDBMSHOME and run ‘postpatch’:$ORACLEHOME/OPatch/opatch napply -oh $RDBMSHOME -local /u01/software/psuoct2016/12cGI/2446101cd /u01/software/psuoct2016/12cGI/2444735/custom/scripts./postpatch.sh7. As root:/u01/app/12.1.0/grid/rdbms/install/rootaddrdbms.sh$GRIDHOME/crs/install/rootcrs.pl -postpatchExecuting the final command 'rootcrs.pl -postpatch' with lock the crs files and start the cluster servicesWait for 2-3 minutes – till all CRS components are started and DB is in OPEN state/u01/app/12.1.0/grid/bin/crsctl stat res -t8. As ‘oracle’:$ORACLEHOME/bin/srvctl start home -o $RDBMSHOME -s /tmp/status1 -n node1(No Output)9. As ‘oracle’:ps -ef grep pmon10.

Patch

Verify the Patches on both GI and RDBMS HOMES:$ORACLEHOME/OPatch/opatch lsinventory -oh $RDBMSHOME$ORACLEHOME/OPatch/opatch lsinventory -oh $RDBMSHOME grep 24007012$ORACLEHOME/OPatch/opatch lsinventory -oh $RDBMSHOME grep 23854735$ORACLEHOME/OPatch/opatch lsinventory -oh $GRIDHOME$ORACLEHOME/OPatch/opatch lsinventory -oh $GRIDHOME grep 24007012$ORACLEHOME/OPatch/opatch lsinventory -oh $GRIDHOME grep. Check the status of CRS components:$ crsstat -tNode 2. $ $ORACLEHOME/bin/srvctl stop home -o $RDBMSHOME -s /tmp/status -n node2Follow steps 2-7 from the Node 1 section8. As ‘oracle’:$ORACLEHOME/bin/srvctl start home -o $RDBMSHOME -s /tmp/status1 -n node2(No Output)9. As ‘oracle’:ps -ef grep pmon10. Verify the Patches on both GI and RDBMS HOMES:$ORACLEHOME/OPatch/opatch lsinventory -oh $RDBMSHOME$ORACLEHOME/OPatch/opatch lsinventory -oh $RDBMSHOME grep 24007012$ORACLEHOME/OPatch/opatch lsinventory -oh $RDBMSHOME grep 23854735$ORACLEHOME/OPatch/opatch lsinventory -oh $GRIDHOME$ORACLEHOME/OPatch/opatch lsinventory -oh $GRIDHOME grep 24007012$ORACLEHOME/OPatch/opatch lsinventory -oh $GRIDHOME grep.

Check the status of CRS components:$ crsstat -tPost -Patch Instructions:On Node 1:cd $RDBMSHOME/OPatch./datapatch -verboseHope this has helped you in some way.If yes, please don't forget to add a comment!

Comments are closed.