the Oracle RAC database environment has a lot in common with a single-instance database environment, as well as many heterosexual. The same is true for updates to database patches, which can be done through Opatch. However, patch updates for the RAC environment are updated in several different ways, and even rolling upgrades can be implemented for all nodes in the case of a 0 outage. This article is mainly about Doc 244241.1, describing how patches are updated in a RAC environment, and how to choose which updates in different situations.
1. Several ways of RAC patch
Opatch supports 3 different patch methods on a RAC environment:
- Patching RAC as a single instance (All-node Patch) (stop 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 is down during the whole patching process.
- Patching RAC using a minimum down-time strategy (min. Downtime Patch) (minimized down mode)
In this mode, opatch patches the local node, asks users for a sub-set of nodes, which would be the first subset of node s to be patched. After the initial subset of nodes is patched, Opatch propagates the patch to the other nodes and finally updates the INVe Ntory. The downtime would happen between the shutdown of the second subset of nodes and the startup of the initial subset of node s patched.
- Patching RAC using a rolling strategy-no down time (rolling Patch) (scrolling mode)
With this method, the there is no downtime. Each node would is patched and brought up while all the other nodes is 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 Ste PS, 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 ways of patch
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 the instances on nodes 1 and 2 can is 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. How to Choose Patch
To is eligible as a rolling patch, the patch needs to meet certain criterias, which is determined by Oracle developers. In order to being applied in a "rolling fashion", the patch must is designated as a "rolling updatable patch" or simply "roll ing patch ".
The algorithm used to decide which method are going to being used is the following:
If (Users specify Minimize_downtime)
Patching mechanism = Min. Downtime
else if (patch is a rolling patch)
Patching mechanism = rolling
Else
Patching mechanism = All-node
#从上面的算法来看最小化停机时间是首选.
4. Availability of rolling patches
When Patches is released, they has a tag as "rolling" or "Not rolling" patch. While the most patches can is applied in a rolling fashion, some patches can is applied in this fashion. Patches that could potentially is installed on rolling fashion include:
. Patches that does not affect the contents of the database.
. Patches that is not related to the RAC internode communication infrastructure.
. Patches that change procedural logic and does not modify common header definitions of kernel modules. This includes client side patches is affect utilities like export, import, Sql*plus, Sql*loader, etc.
Only individual patches – not patch sets – would be "rollable". It should also be noted, a merge patch of a "rolling patch" and an ordinary patch would not be a "rolling patch".
From 9.2.0.4 onwards, all patches released would be marked as a "rolling" or "not rolling patches", based on defined set of R Ules. Patches previously released is packaged as "not rolling".
Because the set of rules currently defined is very conservative, patches released as "not rolling patches", either before And after 9.2.0.4, the May is eligible to being re-released as "rolling Patches" after an analysis from Oracle development.
If you plan to apply a patch which is marked as "not rolling" and want to check if are possible to take advantage of the Rol Ling Patch strategy, contact Oracle support.
5. How to confirm whether patches are scrollable
#可使用下面的方式来查询当前的patch是否为可滚动
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 isn't work if unzipped patch location have more than one patch sub-directory, example output while checking C PU Patches:
#对于解压路径下有多个子patch的情形, verifying whether a rolling patch might fail, as follows:
Failed to load the patch object. Possible causes is:
The specified path is a interim Patch shiphome
Meta-data files is 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. Some Current limitations
Patching with Shared File System
Currently Opatch treats Shared File System, like CFS, as a single-instance patch. It means that Opatch would blindly patch files under a given oracle_home knowing that other nodes would pick up the changes Via the Shared File System. Unfortunately, this means the opatch cannot take advantage of a rolling patch on a Shared File System environment; All nodes must is down throughout the patching process.
Patching one node at time
The Opatch strategies discussed above (All-node, Min. Down-time, and rolling) presumes, all nodes would be patched at t He same time. Additionally, each node can is patched individually, at different times, using the "-local" key word, which would patch onl Y the local node.
