Oracle RAC環境下如何更新patch(Rolling Patch)，racrolling
Oracle RAC資料庫環境與單一實例資料庫環境有很多共性，也有很多異性。對於資料庫補丁的更新同樣如此，都可以通過opatch來完成。但RAC環境的補丁更新有幾種不同的更新方式，甚至於可以在零停機的情況下對所有節點實現滾動升級。本文主要是轉述了Doc 244241.1，描述RAC環境下的patch更新方式以及在不同的情形下選擇何種更新方式。
1、RAC patch的幾種方式
OPatch supports 3 different patch methods on a RAC environment:
- Patching RAC as a single instance (All-Node Patch) (停機方式)
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)(最小化停機方式)
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 would 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)(滾動方式)
With this method, there is no downtime. Each node would 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.
注意這句話，Rolling Patch不會停機，但是有些指令碼可能會引發宕機。
2、不同方式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 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、選用何種方式patch
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 mechanism = Min. Downtime
else if (patch is a rolling patch)
patching mechanism = Rolling
else
patching mechanism = All-Node
#從上面的演算法來看最小化停機時間是首選。
4、滾動patch的可用性
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 could 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 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 should 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 previously 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 eligible 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 is possible to take advantage of the rolling patch strategy, please contact Oracle Support.
5、如何確認patch是否可滾動
#可使用下面的方式來查詢當前的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 not work if unzipped patch location has more than one patch sub-directory, example output while checking CPU patches:
#對於解壓路徑下有多個子patch的情形，校正是否為滾動patch可能會失敗，如下：
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、當前的一些限制
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 資料同步
你說的這種情況有點匪夷所思, 鎖機制與RAC構架並無衝突,在同一個DB下對資料進行修改,不論是否並行, 對錶資料的加鎖必然是唯一性的, 請從程式邏輯層面進行分析
備份Oracle RAC環境資料庫的時,只備份一台與備份兩台是否有不同？
環境一：
1、參數檔案使用spfile的話，就是一致的，使用pfile的話，那可能就不一致了。
控制檔案肯定是一樣的。
2、Archivelog 不一樣
3、恢複方式和單一實例一樣，只需要保證做恢複的那個節點能訪問到兩個節點的歸檔日誌即可
環境二：
1、參數檔案使用spfile的話，就是一致的，使用pfile的話，那可能就不一致了。
控制檔案肯定是一樣的。
2、Archivelog 不一樣
3、備份任意一個節點的Database、Controlfile，備份兩個節點的Archivelog
問題補充：
一般採用指令碼A
