How to update a patch (Rolling Patch) in the Oracle RAC Environment
The Oracle RAC database environment has many similarities and differences with the single-instance database environment. You can use opatch to update database patches. However, there are several different update Methods for the RAC environment patch update, and you can even implement rolling upgrade for all nodes without downtime. This article describes the patch update method in the RAC environment and the update method selected under different circumstances.
1. Several Methods of RAC patch
OPatch supports 3 different patch methods on a RAC environment:
- Patching RAC as a single instance (All-Node Patch) (downtime Mode)
In this mode, OPatch applies the patch to the local node first, then propagates the patch to all the other nodes, and finally updates the inventory. all instances must be down during the whole patching process.
- Patching RAC using a minimum down-time strategy (Min. Downtime Patch) (minimal Downtime)
In this mode, OPatch patches the local node, asks users for a sub-set of nodes, which will be the first subset of nodes to be patched. after the initial subset of nodes are patched, Opatch propagates the patch to the other nodes and finally updates the inventory. the downtime wowould happen between the shutdown of the second subset of nodes and the startup of the initial subset of nodes patched.
- Patching RAC using a rolling strategy-No down time (Rolling Patch) (rolling mode)
With this method, there is no downtime. Each node wocould be patched and brought up while all the other nodes are up and running, resulting in no disruption of the system.
Rolling patching strategy incur no downtime, however, some rolling patches may incur downtime due to post-installation steps, I. e. running SQL scripts to patch the actual database. please refer to patch readme to find out whether post-installation steps requires downtime or not.
Note that Rolling patches do not stop, but some scripts may cause downtime.
2. Steps for different Patch methods
All-Node Patch
. Shutdown all Oracle instances on all nodes
. Apply the patch to the RAC home on all nodes
. Bring all instances up
Minimum downtime
. Shutdown the Oracle instance on node 1
. Apply the patch to the RAC home on node 1
. Shutdown the Oracle instance on node 2
. Apply the patch to the RAC home on node 2
. Shutdown the Oracle instance on node 3
. At this point, instances on nodes 1 and 2 can be brought up
. Apply the patch to the RAC home on node 3
. Startup the Oracle instance on node 3
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
3. Method of patch Selection
To be eligible as a rolling patch, the patch needs to meet certain criterias, which are determined by Oracle developers. in order to be applied in a "rolling fashion", the patch must be designated as a "rolling updatable patch" or simply "rolling patch ".
The algorithm used to decide which method is going to be used is the following:
If (users specify minimize_downtime)
Patching mechanic = Min. Downtime
Else if (patch is a rolling patch)
Patching mechanic = Rolling
Else
Patching mechanic = All-Node
# From the above algorithm, minimizing the downtime is the first choice.
4. Availability of rolling patches
When patches are released, they have a tag as "rolling" or "not rolling" patch. while most patches can be applied in a rolling fashion, some patches can not be applied in this fashion. patches that cocould potentially be installed on rolling fashion include:
. Patches that do not affect the contents of the database.
. Patches that are not related to the RAC internode communication infrastructure.
. Patches that change procedural logic and do not modify common header definitions of kernel modules. this includes des client side patches that only affect utilities like export, import, SQL * plus, SQL * loader, etc.
Only individual patches -- not patch sets -- will be "rollable ". it shoshould also be noted that a merge patch of a "rolling patch" and an ordinary patch will not be a "rolling patch ".
From 9.2.0.4 onwards, all patches released will be marked as a "rolling" or "not rolling patch", based on defined set of rules. Patches previusly released are packaged as "not rolling ".
Because the set of rules currently defined are very conservative, patches released as "not rolling patches", either before and after 9.2.0.4, may be eligvisible to be re-released as "rolling patches ", after analysis from Oracle Development.
If you plan to apply a patch that is marked as "not rolling" and want to check if it is possible to take advantage of the rolling patch strategy, please contact Oracle Support.
5. How to check whether the patch can be rolled
# You can use the following method to check whether the current patch is rolling.
As database user execute the following:
-9i or 10gR1: opatch query-is_rolling
-10gR2: opatch query-all [unzipped patch location] | grep rolling
-10gR2 on Windows: opatch query-all [unzipped patch location] | findstr rolling
-Later 10gR2 or 11g: opatch query-is_rolling_patch [unzipped patch location]
The command may not work if unzipped patch location has more than one patch sub-directory, example output while checking CPU patches:
# If there are multiple sub-patches in the decompression path, check whether the Rolling patch is used may fail, as shown below:
Failed to load the patch object. Possible causes are:
The specified path is not an interim Patch shiphome
Meta-data files are missing from the patch area
Patch location =/home/oracle/stage/8836308
Details = Input metadata files are missing.
Patch Location "/home/oracle/stage/8836308" doesn't point to a valid patch area.
# Author: Leshami
# Blog: http://blog.csdn.net/leshmai
OPatch failed with error code 75
6. Current restrictions
Patching with Shared File System
Currently OPatch treats Shared File System, like CFS, as a single-instance patch. it means that OPatch will blindly patch files under a given ORACLE_HOME knowing that other nodes will pick up the changes via the Shared File System. unfortunately, this means that OPatch cannot take advantage of a rolling patch on a Shared File System environment; all nodes must be down throughout the patching process.
Patching one node at time
The Opatch strategies discussed above (All-Node, Min. down-Time, and Rolling) presumes that all nodes will be patched at the same time. additionally, each node can be patched individually, at different times, using the "-local" key word, which will patch only the local node.
Oracle rac Data Synchronization
The situation you mentioned is a bit incredible. The lock mechanism does not conflict with the RAC architecture. data modification in the same database, whether or not it is in parallel, must be unique to lock table data, analyze the Program Logic
When backing up an Oracle RAC environment database, is there a difference between backing up only one database and backing up two databases?
Environment 1:
1. If the parameter file uses spfile, It is consistent. If pfile is used, it may be inconsistent.
The control files must be the same.
2. Archivelog is different.
3. The recovery method is the same as that of a single instance. You only need to ensure that the node to be restored can access the archived logs of the two nodes.
Environment 2:
1. If the parameter file uses spfile, It is consistent. If pfile is used, it may be inconsistent.
The control files must be the same.
2. Archivelog is different.
3. Back up the Database and Controlfile of any node, and back up the Archivelog of the two nodes.
Question added:
Generally, script A is used.
