【RAC】RAC相關基礎知識

1.CRS簡介

   從Oracle 10G開始，oracle引進一套完整的叢集管理解決方案—-Cluster-Ready Services，它包括叢集連通性.訊息和鎖.負載管理等框架.從而使得RAC可以脫離第三方叢集件，當然，CRS與第三方叢集件可以共同使用.

(1).CRS程式

CRS主要由三部分組成，三部分都作為守護程式出現

<1>CRSD：資源可用性維護的主要引擎.它用來執行高可用性恢復及管理操作，諸如維護OCR及管理應用資源，它儲存著叢集的資訊狀態和OCR的配置，此程式以root許可權執行.

<2>EVMD：事件管理守護程式.此程式還負責啟動racgevt程式以管理FAN伺服器端呼叫，此程式以root許可權執行

<3>OCSSD：叢集同步服務程式.管理叢集節點的成員資格，它以fatal方式啟動，因此程式發生故障將導致叢集重啟，以防止資料壞死.同時，CSS還維護叢集內的基本鎖功能，以及負責監控voting disk的腦裂故障。它以Oracle許可權執行

此外，還有一個程式OPRCD，他是叢集中的程式監視程式，僅當平臺上的CRS不使用廠商群件時候才出現，且無論執行了多少例項，每個節點只會存在一組後臺程式.

來看一下這幾個守護程式: 

rac1-> cat/etc/inittab

…………………………….

# Run xdm in runlevel 5

x:5:respawn:/etc/X11/prefdm –nodaemon

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null

h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

 

  (2).Virtual IP Address

Oracle 10G RAC下，有3個重要的IP.

① Public IP  ② Private IP  ③ Vitual IP

Public IP為資料庫所在主機的公共網路IP，Private IP被用來私有高速互聯，而Oracle較前版本，增加了一個虛擬IP，用來節點發生故障時候更快的故障轉移，oracle利用每個節點的lisnter偵聽VIP，一旦發生故障，VIP將進行實際的故障切換，從而在其他的可用的節點上保持聯機，從而降低客戶應用程式意識到節點故障所需要的時間。

VIP與Public IP必須在同一個網段內。

(3).OCR，Voting disk
      OCR(oracle叢集登錄檔)和Voting disk(表決磁碟)是CRS下的兩個重要元件，它們必須放在共享磁碟上，以保證每個節點都能對其訪問。

OCR包含了針對叢集的一些配置資訊，諸如:叢集資料庫中的節點列表.CRS應用程式.資原始檔以及事件管理器的授權資訊。他負責對叢集內的資源追蹤，從而獲知資源正在哪裡執行，應該可以在哪裡執行。

Voting disk用來解決split-brain故障:如果節點丟失了與叢集中其他節點的網路連線，這些衝突由表決磁碟中的資訊來解決

2.ASM相關 

ASM (Automated Storage Management) 是Oracle 10G引入的一種檔案型別，他提供了直接的I/O讀寫，是RAC體系下一套不錯的對資料檔案儲存規劃的方案. ASM可以自動管理磁碟組，並提供資料冗餘和優化.後面章節會就ASM的管理以及ASM下的RAC管理，單獨講解.

3.RAC儲存/網路需求

 

(1).儲存需求

共享儲存器是RAC的重要元件之一。它要求叢集內的節點可以同時讀寫物理磁碟。目前，支援共享儲存的檔案型別也比較多，像Oracle自身提供的ASM，OCFS2以及三方提供的群集檔案系統，都是可以選擇的型別。

表1.1.1顯示了RAC 體系架構下各部分所支援的儲存型別 (暫不考慮三方叢集檔案系統，就ASM/raw device/OCFS2和普通檔案系統來說)

表1.1.1  RAC各部分所支援的儲存型別

類別	支援的儲存型別	儲存位置	備註
Cluster 軟體	OCFS2，普通檔案系統	共享磁碟/本地磁碟
OCR，Voting disk	OCFS2，raw device	共享磁碟
資料庫軟體	OCFS2，普通檔案系統	共享磁碟/本地磁碟
資料庫檔案	OCFS2，raw device，ASM	共享磁碟
歸檔日誌檔案	OCFS2，ASM，普通檔案系統	共享磁碟/本地磁碟
備份/恢復檔案	OCFS2，ASM，普通檔案系統	共享磁碟/本地磁碟
閃回日誌檔案	OCFS2，ASM	共享磁碟

(2).網路需求

  每個節點主機上至少需要2張物理網路卡，以便分配公有IP和私有IP地址。對於私有IP連線，每個叢集節點通過專用高速網路連線到所有其他節點，目的在於叢集上的節點和例項交換資訊狀態（鎖資訊，全域性快取資訊等）。通過高速互聯，Cache Fusion得以實現。

  在實際環境中，高速互聯至少需要配置GB級的乙太網，而且，最好不要使用交叉直連。

較好的解決方案是節點間配置專用交換機，這樣避免因為叢集上一個節點宕掉而影響另外節點的正常工作。

4.其他

(1).後臺程式

 

圖1.4.1 Backgroud Process in RAC 10g

      由於要維護多個例項同時訪問資源所必需的鎖定，因此，同single instance相比，RAC下增加了額外的一些程式。專門針對RAC的程式有如下幾種：

1.  LMS(Global Cache Service)  全域性快取服務程式

     LMS負責為快取融合請求在例項間傳遞塊。當一致性請求的時候，LMS首先回滾塊，建立塊的讀一致性映像（CR），然後將該一致性版本通過高速互聯傳遞到處理此請求的遠端例項中的前臺程式上，LMS程式保證了在同一時刻只允許一個例項去更新資料塊。

     LMS程式的數量由初始化引數GCS_SERVER_PROCESSES控制。Oracle最大支援36個LMS程式（0–9 and a–z），該初始化引數預設值為2。

2.  LMD (Global Enqueue Service Daemon) 全域性佇列服務守護程式

     LMD負責管理全域性佇列和全域性資源訪問，並更新相應佇列的狀態，此外還負責遠端節點資源的請求與死鎖的檢測。LMD與LMS程式互交工作，共同維護GRD。

3.  LMON (Global Enqueue Service Monitor) 全域性佇列服務監控器程式

     LMON是全域性佇列服務的監控器，他負責檢查叢集內例項的死亡情況併發起重新配置，當例項加入或者離開叢集的時候，它負責重新配置鎖和資源。

4.  LCK(Lock process) 鎖程式

     LCK管理那些不是快取融合的請求，例如library cahe, row cache.由於LMS程式提供了主要的鎖管理功能，因此每個節點例項上只有一個LCK程式。

DIAG (The Diagnostic Daemon）診斷守護程式

     DIAG負責監控例項的健康狀況並捕獲程式失敗的資訊，並將失敗資訊寫入用於失敗分析，該程式自動啟動且不需要人為調整，若失敗則自動重新啟動。

(2).快取融合/快取一致性

      Cache Fusion是RAC工作原理的一箇中心環節.他的本質就是通過網際網路絡在叢集內各節點的SGA之間進行塊傳遞，從而避免了首先將塊推送到磁碟，然後再重新讀入其他例項的快取中，從而最大限度的減少I/O。當一個塊被讀入RAC環境中某個例項的快取時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他例項知道該塊正在被使用。之後，如果另一個例項請求該塊的一個拷貝，而該塊已經處於前一個例項的快取內，那麼該塊會通過網際網路絡直接被傳遞到另一個例項的SGA。如果記憶體中的塊已經被改變，但改變尚未提交，那麼將會傳遞一個CR副本。這就意味著，只要可能，資料塊無需寫回磁碟即可在各例項快取之間移動，從而避免了同步多例項的快取所花費的額外I/O，由此，需要網際網路絡的速度是高速的，需要快於磁碟訪問的速度．

      GCS負責維護全域性緩衝區內的快取一致性，LMS程式是其主要組成部分。GCS確保同一時刻某個塊上，只能有來自一個例項上的程式能對其修改,同時，並獲得該塊的當前版本和前映像，以及塊所處的狀態（NULL,,Shared, Exclusive），模式(local/gobal)。

     GES負責維護dictionary cache和library cache快取一致性（這個與LCK是不同的）。由於存在某個節點上對資料字典的修改(比如ddl和dcl對object屬性的修改)，GES負責同步各節點上的字典快取,消除差異。GES確保請求訪問相同物件的多個例項間不會出現死鎖。

     GRD包含了所有共享資源的當前狀態資訊，它由GES和GCS共同維護，GRD貯存在記憶體中，被用來管理全域性資源活動。比如：當一個例項第一次讀取某塊到SGA的時候，該塊的角色為LOCAL，GCS記錄此狀態到GRD，一旦有另外的例項請求該塊，GCS會更新GRD，將此塊的角色由LOCAL變為GLOBAL。

二 RAC安裝

不用把安裝RAC看成是多麼困難的一件事情.足夠細心和耐性，充分的準備工作，然後加上一丁點運氣，相信你能很快部署好一個RAC測試環境.當然，虛擬環境和實際環境的安裝不盡相同，而且，生產系統環境的搭建需要經過縝密的規劃和系統的測試.但大同小異，安裝過程不該稱為我們的絆腳石.

1.安裝規劃部署

安裝之前需重點規劃RAC系統各檔案的儲存型別.可以參見表1.3.1。一個好的儲存規劃方案，可以省去很多後續的維護成本。

2. 安裝過程

安裝過程可以參考oracle聯機文件install guid。(Vmware安裝可以參考Vincent Chan發表在oracle網站上的一文<使用 VMware Server 在 Oracle Enterprise Linux 上安裝 Oracle RAC 10g>.文中講的很詳細，在此簡單帶過.)。簡單列一下安裝RAC的幾個重要步驟

配置系統核心引數以及環境

配置共享儲存

安裝CRS軟體

安裝RDBMS軟體

建立資料庫以及配置其他

3.幾點注意問題.

特別提一下vmware下的時間同步問題，在我的環境下，兩節點上時間差別很大.一開始採用vmware-toolbox工具同步宿主時間，效果不理想.可以在每個節點上放置一個小指令碼，讓他每隔一段時間以另一個節點為基準同步時間.這樣，時間同步問題迎刃而解.在我的環境下，我設定每20秒同步一次時間.

rac1>cat date.sh

#!/bin/sh

while true

do

rdate -s rac2>dev/null 2>&1

sleep 10

done

三 RAC管理維護

同Single instance相比，RAC的管理維護要複雜一些。10g給我們提供了一個強大的EM管理工具，將很多管理維護工作簡單和介面化。我們也應當習慣使用EM來高效的完成更多的工作。本文以下部分，將暫不討論EM方面的管理，著重於命令列方式。

1.CRS管理維護

(1).CRS相關的介面命令

CRS在10G RAC體系下有著舉足輕重的作用。Oracle也提供了一些命令介面讓我們診斷維護它。

<1>CRS_*

10G RAC下，有這麼幾組crs_命令維護CRS資源。

 

[root@rac2 bin]# ls $ORA_CRS_HOME/bin|grep "crs_"|grep -v bin
crs_getperm  crs_profile  crs_register  crs_relocate  crs_setperm  crs_start  crs_stat  crs_stop  crs_unregister

下面分別講述一下它們。

叢集資源查詢：CRS_STAT

可以用來檢視RAC中各節點上resources的執行狀況,Resources的屬性等。

例如使用－t選項，檢查資源狀態：

[root@rac1 ~]# crs_stat –t

Name Type Target State Host

ora.demo.db application ONLINE ONLINE rac2

ora....o1.inst application ONLINE ONLINE rac1

ora....o2.inst application ONLINE ONLINE rac2

ora....SM1.asm application ONLINE ONLINE rac1

ora....C1.lsnr application ONLINE ONLINE rac1
ora.rac1.gsd application ONLINE ONLINE rac1

ora.rac1.ons application ONLINE ONLINE rac1

ora.rac1.vip application ONLINE ONLINE rac1

ora....SM2.asm application ONLINE ONLINE rac2

ora....C2.lsnr application ONLINE ONLINE rac2

ora.rac2.gsd application ONLINE ONLINE rac2

ora.rac2.ons application ONLINE ONLINE rac2

ora.rac2.vip application ONLINE ONLINE rac2

利於-p選項，獲得資源配置屬性。

[root@rac2 bin]# crs_stat -p ora.rac2.vip

NAME=ora.rac2.vip

TYPE=application

ACTION_SCRIPT=/opt/oracle/product/10.2.0/crs_1/bin/racgwrap

ACTIVE_PLACEMENT=1

AUTO_START=1

CHECK_INTERVAL=60

DESCRIPTION=CRS application for VIP on a node

…………………………………………

USR_ORA_STOP_MODE=immediate

USR_ORA_STOP_TIMEOUT=0

USR_ORA_VIP=192.168.18.112

利用-p引數，獲得資源許可權。

[root@rac2 bin]# crs_stat -ls|grep vip

ora.rac1.vip root oinstall rwxr-xr—

ora.rac2.vip root oinstall rwxr-xr--

主要引數有-t/-v/-p/-ls/-f等。具體可以參見crs_stat –h

叢集資源啟動/停止CRS_START/CRS_STOP

這組命令主要負責各個節點上resources的啟動/停止。可以針對全域性資源(例如：crs_stop –all，表示停止所有節點上的resources),也可以針對節點上的某個特定的資源（例如：crs_start ora.rac2.ons,表示啟動節點rac2上的ONS）。

叢集資源配置CRS_REGISTER/CRS_UNREGISTER/CRS_PROFILE/CRS_SETPERM

這組命令主要負責叢集資源的新增刪除以及配置。

CRS_PROFILE:用來生成resource的profile檔案(當然我們也可以手動編輯或者通過現有生成)，預設存放路徑$ORA_CRS_HOME/crs/profile目錄下，加引數-dir 手動指定目錄。預設名稱為resource_name.cap.

crs_profile -create resource_name -t application –a .. –r .. –o..

表3.1為 crs_profile中引數配置說明（比較多，挑一些說吧）：

引數名稱	說明	引數指令（以create為例）
NAME	資源名稱	crs_profile –create resource_name
TYPE	資源型別(application, generic)	crs_profile – create resource_name –t …
ACTION_SCRIPT	用來管理HA方案指令碼	crs_profile – create resource_name –a …
ACTIVE_PLACEMENT	資源貯存的位置/節點	crs_profile –create resource_name –o –ap …
AUTO_START	資源自啟動	crs_profile –create resource_name –o –as …
CHECK_INTERVAL	資源監控間隔	crs_profile –create resource_name –o –ci …
FAILOVER_DELAY	資源failover的等待時間	crs_profile –create resource_name –o –fd …
FAILURE_INTERVAL	資源重啟嘗試間隔	crs_profile –create resource_name –o –fi …
FAILURE_THRESHOLD	資源重啟嘗試次數(最大20次)	crs_profile –create resource_name –o –ft …
HOSTING_MEMBERS	資源啟動或者failover的首要節點選擇	crs_profile –create resource_name –h …
PLACEMENT	資源啟動或者failover的節點選擇模式（balanced，balanced，balanced）	crs_profile – create resource_name -p
REQUIRED_RESOURCES	當前資源所依賴的資源	crs_profile – create resource_name -r
RESTART_ATTEMPTS	資源重配置之前的嘗試啟動次數	crs_profile –create resource_name –o –ra …
SCRIPT_TIMEOUT	等待ACTION_SCRIPT的結果返回時間	crs_profile –create resource_name –o –st …
USR_ORA_VIP	Vip地址	crs_profile –create vip_name -t application –a $ORA_CRS_HOME/bin/uservip –o oi=…,ov=…,on=…

crs_profile －update resource_name … 用來更新現有profile(更新的只是profile，而並不是對已經註冊到crs裡面的資源屬性的更改)

crs_register負責將resource的註冊到OCR。註冊的方法是先生成profile，然後執行

crs_register resource [-dir …]命令，同時，crs_register也具有update resource功能，具體辦法可以更新resource對應的profile檔案，然後執行crs_register -u resource_name [-dir …] 或者直接釋出crs_register –update resource_name …

比如，我將rac節點上的vip改為手動啟動。

[root@rac1 crs]# crs_register -update ora.rac1.vip -o as=0

[root@rac1 crs]# crs_stat -p ora.rac1.vip|grep AUTO_START

AUTO_START=0

crs_unregister負責將resource從ocr中移除。必要時候需要加－f引數。

crs_setperm用來設定resource的許可權（諸如設定owner，使用者的讀寫許可權等），更改owner用-o引數，更改group用-g，更改使用者許可權用-u，在此不多舉例了。

<2>.CRSCTL

用crsctl check crs，檢查crs的健康情況。

[root@rac1 ~]# crsctl check crs

CSS appears healthy

CRS appears healthy

EVM appears healthy

用crsctl控制CRS服務

crsctl start|stop|enable|disable crs

用crsctl啟動/停止resource

[root@rac1 ~]# crsctl stop resources

Stopping resources.

Successfully stopped CRS resources

[root@rac1 ~]# crsctl start resources

Starting resources.

Successfully started CRS resources

用crsctl檢查以及新增、刪除voting disk

下面講述。

更多參見crsctl help。

<3>SRVCTL

SRVCTL是一個強大的CRS和RDBMS的管理配置工具。相關用法參照srvctl -h

（1） srvctl add/delete .. 新增刪除資源。譬如我們在進行資料庫單例項遷移到rac的時候，可以用這個工具手工註冊database或者asm例項到OCR。

（2） srvctl status … 資源的狀態監測

（3） srvctl start/stop … 資源的啟動/停止，這個可以和crs_start/crs_stop互交使用。

（4） srvctl modify .. 重新定義資源的屬性

………………………………………………………..

(2).OCR的管理維護
<1> OCR的狀態驗證：

可以使用ocrcheck工具來驗證OCR的狀態以及空間使用情況。在Lunix下，/etc/oracle/ocr.loc檔案記錄了OCR使用的裝置情況。

[root@rac1]# ocrcheck

Status of Oracle Cluster Registry is as follows :

Version : 2

Total space (kbytes) : 497896

Used space (kbytes) : 3996

Available space (kbytes) : 493900

ID : 958197763

Device/File Name : /dev/raw/raw5

Device/File integrity check succeeded

Device/File not configured

Cluster registry integrity check succeeded

<2> 線上新增/刪除ocrmirror

OCR支援一個映象，新增/刪除映象可以線上完成，主要在某個online的節點上執行命令即可。

[root@rac1]#ocrconfig -replace ocrmirror /dev/raw/raw5

[root@rac1 oracle]# cat /etc/oracle/ocr.loc

#Device/file getting replaced by device /dev/raw/raw5

ocrconfig_loc=/dev/raw/raw1

ocrmirrorconfig_loc=/dev/raw/raw5

可見，ocr.loc被自動更新。

移除ocr或者映象的時候，只要不帶路徑，即可。

當一個crs中存在ocr和映象的時候，如果移除ocr，映象會自動轉變成ocr的角色。

[root@rac1]# ocrconfig -replace ocr

[root@rac1]# cat /etc/oracle/ocr.loc

#Device/file /dev/raw/raw1 being deleted

ocrconfig_loc=/dev/raw/raw5

可以看到現在的ocrconfig_loc自動變為先前的ocrmirrorconfig_loc裝置。

<3> 邏輯備份/恢復

備份命令：

ocrconfig –export [ path ]

還原命令

ocrconfig –import [ path ]

還原OCR的時候，需要停掉各節點crs服務。還原完成後，重新啟動CRS。(如果有必要，注意在每個節點分別修改ocr.loc的對應使用裝置)

<4> 物理備份/恢復

CRSD負責每4個小時進行一次OCR的備份，預設備份路徑在$ORA_CRS_HOME/cdate/crs下，

可以使用ocrConfig –showbackup檢視備份情況，如果想更改物理備份路徑，可以使用ocrconfig –backuploc [ path ] 來完成

物理恢復命令：

ocrconfig –restore [ path ]

同樣,還原OCR的時候，需要停掉各節點crs服務。還原完成後，重新啟動CRS。(如果有必要，注意在每個節點分別修改ocr.loc的對應使用裝置)

<5> ocrdump

ocrdump可以將ocr資訊匯出成ascii文字，用於給Oracle Supoort提供檢修。

命令如下：

ocrdump

(3).Voting disk管理維護
Voting disk的維護相對簡單些。

<1> Votingdisk 狀態查詢

[root@rac1]# crsctl query css votedisk

0 /dev/raw/raw2

located 1 votedisk(s).

<2>線上新增、刪除votingdisk

Oracle建議配置奇數個votingdisk，新增/刪除可以線上完成，在某個online的節點上執行命令即可。

新增votingdisk命令：

crsctl add css votedisk [path] -force

刪除votingdisk命令：

crsctl add css votedisk [path] -force

<3>votingdisk備份恢復

備份、恢復採用dd命令。恢復的時候，注意停掉各節點上的CRS服務。

2.RDBMS管理維護

(1).spfile以及相關引數說明

最普遍情況，節點共用同一個spfile檔案，放置在共享儲存上，而每個節點上，相應目錄下有一個pfile檔案，而這個pfile檔案指向共享儲存上的spfile。

當我們需要修改某一節點上的paremeter的時候，需要顯示的指定sid，例如：

SQL>alter system set sga_target=1024M scope=spfile sid=’rac1’;

System Altered.

這樣，節點rac1上的sga_target引數被修改，不會影響其餘節點上的引數設定。如果不加sid，預設為sid＝’*’，也就是對所有節點生效。

RAC下，有一些不同與單例項的引數，列舉如下：

① cluster_database
一般情況下，該引數在rac各例項下應該設定為true。在一些特別情況下，比如upgrade等，需要將該引數設定成false。
② db_name/db_unique_name/instance_name
各節點db_name需要一致，db_unique_name也需要一致(這與standby是不同的)。而instance_name配置成各個節點的例項名稱。
③ instance_number
該參數列示節點上例項的例項號。
④ thread
該引數用來標示例項使用的redo執行緒。執行緒號與節點號/例項號沒有直接關聯。
⑤ local_listener
該引數用來手工註冊監聽。為解決ORA-12514錯誤，可以設定該引數。
⑥ remote_listener
該引數用來進行伺服器端負載均衡配置。
⑦ cluster_interconnects
該引數用來指定叢集中IPC通訊的網路。如果叢集中有多種網路用於高速互聯，需要配置該引數。對於多個IP地址，用冒號將其隔開。對於叢集中當前使用的互聯地址，可以查詢檢視gv$cluster_interconnects或著oradebug ipc來檢視。
⑧ max_commit_propagation_delay
該引數用於配置SCN的產生機制。在rac下,SCN的同步有2種模式:(1) Lamport Scheme.該模式下，由GES管理SCN的傳播同步，max_commit_propagation_delay表示SCN同步所允許的最大時間。在該模式下，全域性SCN並非完全同步，這在高併發的OLTP系統中，可能會對應用造成一定的影響。(2) Broadcast on Commit scheme. 該模式下，一旦任何一個例項上事務釋出commit，都立即同步SCN到全域性。
在10g R1下，該引數預設數值為700，即採用Lamport Scheme模式。而在10g R2下，該引數預設數值為0，採用Broadcast on Commit scheme模式 (設定小於700的某一值，都將採用該模式) 。採用何種方式，可以從alert.log中獲知。該引數值需要每個節點保持一致。

(2). Redo/Undo管理
?RAC下的Redo管理
同單例項的系統一樣，每個節點例項都需要至少2組logfile。各節點例項有自己獨立的重做日誌執行緒(由初始化引數thread定義)，例如：

SQL> select b.THREAD#,a.GROUP#,a.STATUS,a.MEMBER,b.BYTES,b.ARCHIVED,b.STATUS from v$logfile a,v$log b where a.GROUP#=b.GROUP#;
THREAD# GROUP# STATUS  MEMBER                               BYTES  ARCHIVED  STATUS
------------------- ------- --------------------------------------------------
1  1   STALE +DATA/demo/onlinelog/group_1.257.660614753  52428800 YES  INACTIVE
1  2          +DATA/demo/onlinelog/group_2.258.660614755  52428800  NO   CURRENT
2  3          +DATA/demo/onlinelog/group_3.265.660615545  52428800  NO   CURRENT
2  4  STALE  +DATA/demo/onlinelog/group_4.266.660615543  52428800 YES  INACTIVE

重做日誌需要部署到共享儲存中，必須保證可被所有的叢集內的節點例項訪問。當某個節點例項進行例項/介質恢復的時候，該節點上的例項將可以應用叢集下所有節點例項上的重做日誌檔案(如果需要)，從而保證恢復可以在任意可用節點進行。

?RAC下alter system switch logfile 與alter system archive log current 區別
alter system switch logfile僅對當前釋出節點上的對應redo thread進行日誌切換並歸檔。
alter system archive log current對叢集內所有節點例項上的redo thread進行切換並歸檔（在節點例項可用情況下，分別歸檔到各節點主機的歸檔目的地，當節點不可用時候，該執行緒日誌歸檔到命令釋出節點的歸檔目的地）

?RAC下的Undo管理
RAC下的每個節點例項，也需要有自己單獨的撤銷表空間。由初始化引數 *.Undo_tablespace 指定。同REDO一樣，UNDO表空間也需要部署到共享儲存，雖然每個節點上UNDO的使用是獨立的，但需要保證叢集內其他節點例項對其訪問，以完成構造讀一致性等要求。

SQL>alter system set undo_tablespace=undo1 sid=’demo1’;
SQL>alter system set undo_tablespace=undo2 sid=’demo2’;

(3).Archivelog/flashback配置管理

在RAC下，Archivelog可以放置到本地磁碟，也可以放置到共享儲存。需要對Archivelog的放置有合理的部署，如果放置到本地磁碟，會增加備份恢復的複雜程度。
閃回區必須部署到共享儲存上，開啟前，需要配置db_recovery_file_dest、db_recovery_file_dest_size、db_flashback_retention_target等引數。
下面在一個非歸檔非閃回的database上，開始歸檔與閃回。
?更改相關引數

SQL>alter system set log_archive_dest_1='location=/archive/demo1' sid='demo1';

System altered

SQL> alter system set log_archive_dest_1='location=/archive/demo2' sid='demo2';

System altered

SQL> alter system set db_recovery_file_dest_size=512M;

System altered

SQL> alter system set db_recovery_file_dest='+DG1';

System altered

?停掉所有節點例項.開啟過程在一個例項上完成。

rac1-> srvctl stop instance -d demo -i demo1

rac1-> srvctl stop instance -d demo -i demo2  

rac1-> sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Sun Aug 3 22:06:50 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL> conn /as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Total System Global Area  167772160 bytes

Fixed Size                  1218316  bytes

Variable Size             100665588 bytes

Database Buffers           62914560 bytes

Redo Buffers                2973696 bytes

Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database flashback on;

Database altered.

SQL> alter database open;

Database altered.

SQL> select NAME,LOG_MODE,FLASHBACK_ON from v$database;

NAME      LOG_MODE     FLASHBACK_ON

--------- ------------ ------------------

DEMO      ARCHIVELOG   YES

10G下，開啟歸檔和閃回並不需要像9i那樣，設定初始化引數cluster_database＝false.這無疑簡化了操作。

(4).ASM下的RAC管理
?ASM下的引數檔案

RAC下，每個節點上有執行有一個ASM例項，而rdbms instance就執行在這個asm例項上。Asm例項是本地的。同rdbms例項一樣，他需要有引數檔案，引數檔案在每個節點的相應目錄下。
下面是我的ASM例項下的pfile檔案：

cluster_database=true

background_dump_dest=/opt/oracle/admin/+ASM/bdump

core_dump_dest=/opt/oracle/admin/+ASM/cdump

user_dump_dest=/opt/oracle/admin/+ASM/udump

instance_type=asm

large_pool_size=12M

remote_login_passwordfile=exclusive

asm_diskgroups='DG1'

+ASM2.instance_number=2

+ASM1.instance_number=1

簡單介紹幾個asm例項中比較重要的引數:
instance_type：用來說明例項是ASM 還是RDBMS 型別
asm_diskgroups：ASM磁碟組，asm例項啟動的時候會自動mount
asm_diskstring：該引數用來說明能夠建立diskgroup的磁碟裝置,預設值是NULL
asm_power_limit:該引數用來設定程式 ARBx 的數量，負責控制負載平衡操作的速度。取值 從 0 到 11。預設值為1。

?用於記錄ASM例項資訊的資料字典。
V$ASM_DISK/ V$ASM_DISK_STAT：記錄可以被ASM例項識別的磁碟資訊，但這些磁碟並不一定是正在被例項使用的。
V$ASM_DISKGROUP/ V$ASM_DISKGROUP_STAT：記錄asm下的diskgroup資訊。
V$ASM_ALIAS：記錄diskgroup檔案的別名資訊。
V$ASM_FILE：記錄diskgroup中的檔案資訊。
V$ASM_OPERATION：記錄ASM例項中當前執行的一個長時間操作資訊。
V$ASM_TEMPLATE：記錄diskgroup模板。
V$ASM_CLIENT：記錄使用該asm例項下的diskgroup的rdbms例項資訊。

?RAC下ASM磁碟組/檔案管理操作
<1>.RAC下線上新增、刪除磁碟組
在一個節點上新增diskgroup，叢集上另外的節點並不會自動mount新新增的diskgroup，需要手動執行。
節點1：

SQL> show parameter asm_diskgroups

NAME                                 TYPE        VALUE

------------------------------------ -----------

asm_diskgroups                       string      DATA, DG1

SQL>CREATE DISKGROUP DATA2  NORMAL REDUNDANCY

FAILGROUP DATA2_gp1 DISK '/dev/raw/raw6' FAILGROUP DATA2_gp2 DISK '/dev/raw/raw7';

Diskgroup created.

SQL> show parameter asm_diskgroups

NAME                                 TYPE        VALUE

------------------------------------ -----------

asm_diskgroups                       string      DATA, DG1, DATA2

此時觀察節點2，新加的磁碟組沒有被mount。

SQL> show parameter asm_diskgroups

NAME                                 TYPE        VALUE

-----------------------------------------------

asm_diskgroups                          string        DATA, DG1

SQL>select group_number,type,state,type,total_mb,free_mb from v$asm_diskgroup_stat;

GROUP_NUMBER   STATE       TYPE     TOTAL_MB    FREE_MB

--------------- --------------- ------------------------

           1     CONNECTED   EXTERN       5726       4217

           2     CONNECTED   EXTERN        415        297

           0    DISMOUNTED                     0         0

SQL>alter diskgroup DATA2 mount;

刪除diskgroup時，保留一個節點diskgroup為mount狀態，將其餘節點上的diskgroup dismount，然後執行刪除命令。

<2>.線上新增、刪除磁碟
RAC下線上新增磁碟與刪除磁碟與單例項並不差別。需要注意該操作會引起磁碟組的重新平衡，並確保刪除磁碟的時候該磁碟組有足夠的剩餘空間。
節點1：

SQL> alter diskgroup dg6 add disk '/dev/raw/raw7' name dg6_disk7;

Diskgroup altered.

節點2上查詢：

SQL>select GROUP_NUMBER,path,NAME,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE from v$asm_disk_stat where NAME is not null;

GROUP_NUMBER PATH     NAME       MOUNT_S HEADER_STATU MODE_ST STATE

------------ ---------------- ---------- ------- ------------ -------

           1 /dev/raw/raw3    DATA_0000  CACHED  MEMBER       ONLINE  NORMAL

           2 /dev/raw/raw4    DG1_0000   CACHED  MEMBER       ONLINE  NORMAL

           3 /dev/raw/raw6    DG6_0001   CACHED  MEMBER       ONLINE  NORMAL

           3 /dev/raw/raw7    DG6_DISK7  CACHED  MEMBER       ONLINE  NORMAL

刪除磁碟在某一節點操作即可，不做舉例驗證。
關於ASM的更多管理命令，就不多列舉了。
3.Database備份/恢復

RAC下的備份恢復跟單例項的備份恢復實質上沒有太大的差別，需要注意的是備份/恢復的時候當前節點對所有資料檔案/歸檔日誌的可見。在一個資料檔案和歸檔日誌全部放在共享儲存上的RAC系統，備份與恢復過程與單例項下的幾乎一樣。而歸檔日誌如果採用的是本地磁碟，就需要另加註意。下面分別來模擬這個備份恢復過程。
(1).Archivelog對各節點可見的備份/恢復
在這種模式下，備份恢復可以在任意一個可用節點執行即可，跟單例項並不太大區別。
?對database進行備份

RMAN>run{allocate channel orademo type disk;

backup database format '/backup/database/db_%s_%p_%t' plus archivelog format  '/backup/database/arch_%s_%p_%t' delete input;

backup current controlfile format '/backup/database/contr_%s_%p_%t';}

allocated channel: orademo

channel orademo: sid=130 instance=demo2 devtype=DISK

Starting backup at 03-MAY-08

current log archived

channel orademo: starting archive log backupset

channel orademo: specifying archive log(s) in backup set

input archive log thread=1 sequence=5 recid=70 stamp=661823848

input archive log thread=1 sequence=6 recid=72 stamp=661823865

……………………………………..

Finished backup at 03-MAY-08

released channel: orademo

?新增資料，用於測試恢復效果

SQL> create table kevinyuan.test_b as select * from dba_data_files;

Table created

SQL> alter system switch logfile;

System altered

SQL> insert into kevinyuan.test_b select * from dba_data_files;

6 rows inserted

SQL> commit;

Commit complete

SQL> select count(*) from kevinyuan.test_b;

  COUNT(*)

        12

?模擬故障/恢復

RMAN> run {restore controlfile from '/backup/database/contr_16_1_661823935';

sql 'alter database mount';

restore database;

recover database;

sql 'alter database open resetlogs'; }

Starting restore at 04-MAY-08

allocated channel: ORA_DISK_1

…………………………………………………………………………..

archive log filename=+DATA/demo/onlinelog/group_4.266.660615543 thread=2 sequence=11

archive log filename=+DATA/demo/onlinelog/group_3.265.660615545 thread=2 sequence=12

media recovery complete, elapsed time: 00:00:00

Finished recover at 04-MAY-08

sql statement: alter database open resetlogs

?恢復完畢，來看一下驗證資料：

SQL> select count(*) from kevinyuan.test_b;

  COUNT(*)

        12

(2). Archivelog對各節點不可見的備份/恢復

如果arhivelog採用本地磁碟,歸檔日誌並不是對任意節點可見。備份archivelog的時候，如果採用和上述類似的備份方案，必然會導致一些歸檔日誌由於無法access而丟擲異常。可以採取如下的備份方式，目的就是使得備份通道能夠access所有的資料字典中記錄的歸檔日誌資訊。
恢復的時候,copy所有節點產生的相關備份片/集和歸檔日誌檔案到待恢復節點，在一個節點上執行restore/recover操作即可。
模擬一下這個操作。

SQL> alter system set log_archive_dest_1='location=/archive/demo1/' sid='demo1';

System altered

SQL> alter system set log_archive_dest_1='location=/archive/demo2/' sid='demo2';

System altered

(1)備份資料庫

RMAN>run{allocate channel orademo1 type disk connect sys/kevinyuan@demo1;

allocate channel orademo2 type disk connect

sys/kevinyuan@demo2;

backup database format '/backup/database/db_%s_%p_%t'

plus archivelog format '/backup/database/arch_%s_%p_%t' delete

input;

backup current controlfile format

'/backup/database/contr_%s_%p_%t;}

allocated channel:

orademo1

channel orademo1: sid=133 instance=demo1 devtype=DISK

allocated

channel: orademo2

channel orademo2: sid=151 instance=demo2

devtype=DISK

Starting backup at 04-MAY-08

current log archived

channel

orademo2: starting archive log backupset

channel orademo2: specifying archive

log(s) in backup set

input archive log thread=2 sequence=4 recid=89

stamp=661826286

………………………………………………………………….

channel orademo1: finished

piece 1 at 04-MAY-08

piece handle=/backup/database/contr_28_1_661826504

tag=TAG20080504T004130 comment=NONE

channel orademo1: backup set complete,

elapsed time: 00:00:09

Finished backup at 04-MAY-08

released channel:

orademo1

released channel:

orademo2

(2)COPY節點2上的備份檔案/歸檔日誌檔案到節點1相應目錄下。

rac2-> scp /backup/database/*  rac1:/backup/database/

rac2-> scp /archive/demo2/* rac1:/archive/demo1

(3)恢復database

RMAN>run{restore controlfile from '/backup/database/contr_28_1_661826504';

sql 'alter database mount';

restore database;

recover database;

sql 'alter database open resetlogs';}

starting restore at 04-MAY-08

using target database

control file instead of recovery catalog

allocated channel:

ORA_DISK_1

channel ORA_DISK_1: sid=147 instance=demo1 devtype=DISK

channel

ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete,

elapsed time: 00:00:20

…………………………………………………………………………………

archive log

filename=+DATA/demo/onlinelog/group_3.265.660615545 thread=2

sequence=7

archive log

filename=+DATA/demo/onlinelog/group_4.266.660615543

thread=2 sequence=8

media recovery complete, elapsed time:

00:00:06

Finished recover at 04-MAY-08

sql statement: alter database open

resetlogs

至此，恢復完成。

生產庫的備份需要縝密部署與模擬測試，不同的資料庫型別也需要制定不同的方案實現。對DATABASE來說，備份重於泰山，不能抱有任何僥倖心理。

Service.Failover and Load Balance

1.Service
服務是rac體系中相當重要的概念，它為應用提供高可用和多樣化的解決方案。實際中，我們可以建立不同性質的service來滿足我們應用的不同需求。

10gR2下，可以通過以下幾個方式建立服務。
(1).使用dbca
(2).使用srvctl

node1->srvctl add service -d demo -s srv_1 -r node1 -a node2

node1-> srvctl start service -d demo -s srv_1

node1-> crs_stat –t

Name Type Target State Host

ora.demo.db application ONLINE ONLINE node1

ora….o1.inst application ONLINE ONLINE node1

ora….o2.inst application ONLINE OFFLINE

ora….rv_1.cs application ONLINE ONLINE node1

ora….mo1.srv application ONLINE ONLINE node1

SQL> show parameter service

NAME TYPE VALUE

———————————— ———– ———–

service_names string demo,srv_1

(3).使用dbms_service命令建立
10g提供了dbms_service用於管理服務並進行功能擴充套件.

SQL>EXEC DBMS_SERVICE.CREATE_SERVICE(SERVICE_NAME=>’srv_2′,NETWORK_NAME=>’ srv_2′);

PL/SQL procedure successfully completed

SQL> exec DBMS_SERVICE.START_SERVICE(service_name => ’srv_2′,instance_name => ‘demo1′);

PL/SQL procedure successfully completed

SQL> show parameter service

NAME TYPE VALUE
———————————— ———– ———–

service_names string demo,srv_2

(4).其他等..
不管採用哪種方式，實質都是通過修改service_names而向lisnter動態註冊服務.
2. failover and load banance

RAC為應用提供了高效能和高可用的服務，對使用者來講，核心的功能便是failover與load banance.
(1)Failover
在10gR2版本里，Failover的實現方式有兩種，一種是TAF(Transparent Application Failover), 一種是FCF(Fast Connection Failover).
TAF以及實現:
TAF是net層透明故障轉移,是一種被動的故障轉移方式, 依賴於VIP.可以通過客戶端和伺服器端配置taf的策略.
<1> client端taf配置
以下是一個簡單的具有taf功能的tnsnames.ora 內容

demo =

(DESCRIPTION =

(FAILOVER=ON)

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.145)(PORT=1521))

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.146)(PORT=1521))

(CONNECT_DATA =

(SERVICE_NAME = demo)

(SERVER=DEDICATED)

(FAILOVER_MODE=(TYPE=SELECT)

(METHOD=BASIC)

(RETRIES=50)

(DELAY=5)

)

)

)

控制TAF策略的引數說明：

引數	描述
FAILOVER	Failover控制開關（on/off），如果為off，不提供故障切換功能，但連線時會對address列表進行依次嘗試，直到找到可用為止
TYPE	兩種型別：session /select Session: 提供session級別的故障切換。 Select：提供select級別的故障切換，切換過程對查詢語句透明，但事物類處理需要回滾操作
METHOD	兩種型別:basic/preconnect Basic:client同時只連線一個節點，故障切換時跳轉到另外節點 Preconnect：需要與backup同時使用，client同時連線到主節點和backup節點
BACKUP	採用Preconnect模式的備用連線配置
RETRIES	故障切換時重試次數
DELAY	故障切換時重試間隔時間

<2> Server端TAF配置
10gR2提供Server端的TAF配置，需要呼叫dbms_service包來在例項上進行修改。

SQL> exec dbms_service.modify_service(service_name => ‘DEMO’,failover_method => ‘BASIC’,failover_type => ‘SELECT’,failover_retries => 180,failover_delay => 5);

客戶端連線字串修改成如下即可：

demo =

(DESCRIPTION =

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.145)(PORT=1521))

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.146)(PORT=1521))

(CONNECT_DATA =

(SERVICE_NAME = demo)

(SERVER=DEDICATED)

)

)

FCF及實現
FCF是10g引進的一種新的failover機制，它依靠各節點的ons程式，通過廣播FAN事件來獲得各節點的執行情況，是一種前攝性的判斷，支援JDBC/OCI/ODP.NET
(1).ons配置
onsctl工具配置各節點的local /remote節點以及埠.配置檔案路徑:$ORACLE_HOME/opmn/ons.config.
使用 onsctl debug 跟蹤ons程式是否正常執行。
(2).配置連線池（以jdbc為例）
需要連線池支援Implicit Connection Cache，設定FastConnectionFailoverEnabled=true.
將ojdbc14.jar / ons.jar等加入CLASSPATH.具體程式碼可以參見聯機文件或metalink相關文件.
(2) Load Balance
10g的 load balance同前版本相比有了很大功能上的改進，依據Load Balancing Advisory，提供了Runtime Connection Load Balancing的策略，但個人認為這也是個相對矛盾所在。越是細化的負載均衡機制，越是有加重cache fusion的可能，這對rac的整體效能是個考驗。
load balance主要有兩種實現方式:一種是Connection Load Balancing(CLB)，另外一種是Runtime Connection Load Balancing(RCLB)。
CLB分為客戶端client-side和伺服器端server-side兩種。
client-side需要在tnsname.ora新增LOAD_BALANCE=ON來實現，提供基於平衡連線數的負載方案.
server-side需要修改remote_listener引數,讓listener能監聽到叢集中的所有節點,通過PMON來收集節點上的負載資訊。
FCF預設支援RCLB功能，RCLB通過load balancing advisory事件來對連線提供更好的服務。RCLB有兩種負載平衡方案可供選擇—-基於總體service name和基於總體Throughput。可以通過dbms_service來設定具體的goal方案。

SQL> exec dbms_service.modify_service(service_name => ‘TEST’, goal => DBMS_SERVICE.GOAL_SERVICE_TIME);

至於這兩種方式的具體差異，在我的測試中，並沒有得到明顯的體現。
Load Balanc這部分是我存疑最多的地方，查閱了很多文件，說法不一，且沒有翔實的案例證明，在此也希望有過研究的朋友們做指正。

RAC下其他維護實施相關/案例

本環節側重一些RAC工程維護相關的實際案例,暫舉例以下案例

1.叢集中主機名的更改
2.叢集中IP地址的更改
3.叢集中節點的新增/刪除
4.升級:9i rac升級10g rac
5.rac + dg 搭建
6.其他

<一> 叢集中主機名的更改
以下為一個實際案例，下表為更改前後的主機名稱對比

hostname:node1/node2 —-> td1/td2

private_name:node1_priv/node2_priv —-> td1_priv/td2_priv

vip_name:node1_vip/node2_vip —-> td1_vip/td2_vip

1.生成listener的cap檔案

node1->crs_stat –p ora.node1.LISTENER_NODE1.lsnr>/home/oracle/ora.node1.LISTENER_NODE1.lsnr.cap

node1->crs_stat –p ora.node2.LISTENER_NODE2.lsnr>/home/oracle/ora.node2.LISTENER_NODE2.lsnr.cap

2.停掉所有的資源，備份ocr、votingdisk並重新格式化
備份OCR

[root@node1 backup]# ocrcheck

Status of Oracle Cluster Registry is as follows :

Version : 2

Total space (kbytes) : 104176

Used space (kbytes) : 4424

Available space (kbytes) : 99752

ID : 2042344313

Device/File Name : /dev/raw/raw1

Device/File integrity check succeeded

Device/File not configured

Cluster registry integrity check succeeded

[root@node1 init.d]# ocrconfig -export /backup/ocr_1.bak

備份votedisk

[root@node1 ~]# crsctl query css votedisk

0. 0 /dev/raw/raw110

located 1 votedisk(s).

[root@node1 ~]# dd if=/dev/raw/raw110 of=/backup/votedisk.bak

重新格式化

[root@td01 ~]# dd if=/dev/zero of=/dev/raw/raw1 bs=1024k count=1

[root@td01 ~]# dd if=/dev/zero of=/dev/raw/raw110 bs=1024k count=1

3.OS上修改hostname並編輯相關檔案，重啟主機（步驟略）

4.重新配置叢集互信。（步驟略）

5.編輯$ORA_CRS_HOME/ install/rootconfig檔案，修改以下為你實際的情況。

ORA_CRS_HOME=/opt/oracle/product/10.2.0/crs_1
CRS_ORACLE_OWNER=oracle
CRS_DBA_GROUP=oinstall
CRS_VNDR_CLUSTER=false
CRS_OCR_LOCATIONS=/dev/raw/raw1
CRS_CLUSTER_NAME=crs
CRS_HOST_NAME_LIST=td1,1,td2,2
CRS_NODE_NAME_LIST=td1,1,td2,2
CRS_PRIVATE_NAME_LIST=td1-priv,1,td2-priv,2
CRS_LANGUAGE_ID=’AMERICAN_AMERICA.WE8ISO8859P1′
CRS_VOTING_DISKS=/dev/raw/raw110
CRS_NODELIST=td1,td2
CRS_NODEVIPS=’td1/td1-vip/255.255.255.0/eth0,td2/td2-vip/255.255.255.0/eth0′

在每個節點依次執行：

[root@td2 install]# /opt/oracle/product/10.2.0/crs_1/install/rootconfig

Checking to see if Oracle CRS stack is already configured

Setting the permissions on OCR backup directory

Setting up NS directories

Oracle Cluster Registry configuration upgraded successfully

WARNING: directory ‘/opt/oracle/product/10.2.0′ is not owned by root

WARNING: directory ‘/opt/oracle/product’ is not owned by root

WARNING: directory ‘/opt/oracle’ is not owned by root

WARNING: directory ‘/opt’ is not owned by root

clscfg: EXISTING configuration version 3 detected.

clscfg: version 3 is 10G Release 2.

Successfully accumulated necessary OCR keys.

Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR=49897.

node :

node 1: td1 td1-priv td1

node 2: td2 td2-priv td2

clscfg: Arguments check out successfully.

NO KEYS WERE WRITTEN. Supply -force parameter to override.

-force is destructive and will destroy any previous cluster

configuration.

Oracle Cluster Registry for cluster has already been initialized

Startup will be queued to init within 30 seconds.

Adding daemons to inittab

Expecting the CRS daemons to be up within 600 seconds.

CSS is active on these nodes.

td1

td2

CSS is active on all nodes.

Waiting for the Oracle CRSD and EVMD to start

Oracle CRS stack installed and running under init(1M)

Running vipca(silent) for configuring nodeapps

Creating VIP application resource on (2) nodes…

Creating GSD application resource on (2) nodes…

Creating ONS application resource on (2) nodes…

Starting VIP application resource on (2) nodes…

Starting GSD application resource on (2) nodes…

Starting ONS application resource on (2) nodes…

如果是10.2.0.1 版本，在最後一個節點上執行的時候會因為vip的bug丟擲異常，在該節點上呼叫VIPCA圖形化介面。

這樣gsd、ons和vip已經全部註冊到OCR中。

[root@td1 install]# crs_stat –t

Name Type Target State Host

ora.td1.gsd application ONLINE ONLINE td1

ora.td1.ons application ONLINE ONLINE td1

ora.td1.vip application ONLINE ONLINE td1

ora.td2.gsd application ONLINE ONLINE td2

ora.td2.ons application ONLINE ONLINE td2

ora.td2.vip application ONLINE ONLINE td2

6.使用oifcfg配置共有/私連網路

td1-> oifcfg setif -global eth0/10.194.129.0:public

td1-> oifcfg setif -global eth1/10.10.10.0:cluster_interconnect

7.註冊其他資源到叢集

(1)註冊監聽到叢集
修改監聽配置檔案lisntener.ora並編輯生成的cap檔案（改名），更改其中用到的hostname.

td1-> crs_register ora.td1.LISTENER_TD1.lsnr -dir /home/oracle

td1-> crs_register ora.td2.LISTENER_TD2.lsnr -dir /home/oracle

或者使用netca圖形化介面來配置監聽.

(2)註冊ASM例項到叢集(如果使用ASM)

td1->srvctl add asm -n td1 -i ASM1 -o $ORACLE_HOME

td1->srvctl add asm -n td2 -i ASM2 -o $ORACLE_HOME

(3)註冊instance/database到叢集

td1->srvctl add database -d demo -o $ORACLE_HOME

td1->srvctl add instance -d demo -i demo1 -n td1

td1->srvctl add instance -d demo -i demo2 -n td2

驗證：

td1-> crs_stat -t
Name Type Target State Host
————————————————————
ora.demo.db application ONLINE ONLINE td1
ora….o1.inst application ONLINE ONLINE td1
ora….o2.inst application ONLINE ONLINE td2
ora….SM1.asm application ONLINE ONLINE td1
ora….D1.lsnr application ONLINE ONLINE td1
ora.td1.gsd application ONLINE ONLINE td1
ora.td1.ons application ONLINE ONLINE td1
ora.td1.vip application ONLINE ONLINE td1
ora….SM2.asm application ONLINE ONLINE td2
ora….D2.lsnr application ONLINE ONLINE td2
ora.td2.gsd application ONLINE ONLINE td2
ora.td2.ons application ONLINE ONLINE td2
ora.td2.vip application ONLINE ONLINE td2

登陸資料庫檢查db使用的內連線鏈路

SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— ——————————-
eth1 10.10.10.145 NO Oracle Cluster Repository

如果使用了OCFS作為共享檔案格式，注意在啟動資料庫前檢查相應OCFS的配置並確認ocfs是否能正常掛載使用。

2.叢集中IP地址的更改
IP地址的更改比hostname的更改相對容易一些。對於同網段的public/private IP更改，無需進行特別操作。如果是不同網段，需要使用oifcfg處理。因為VIP是作為資源註冊到OCR，所以任何VIP的改動都需呼叫相關命令進行處理。
以上處理都需要在叢集資源停掉的基礎上操作。
以下是修改前後的public/pricate/vip

Public IP 10.194.129.145/146 –> 10.194.128.145/146
Privite IP 10.10.10.145/146 –> 10.10.1.145/146
Virtual IP 10.194.129.147/148 –> 10.194.128.147/148

1.停掉各資源
資料庫正常關庫，其餘資源使用crs_stop 停止。
2.重新修改網路卡ip/gateway/host檔案等,重啟網路等相關服務
3.利用oifcfg更改public/private ip
檢視當前使用

td1-> oifcfg getif
eth1 10.10.10.0 global cluster_interconnect
eth0 10.194.129.0 global public

刪除當前

td1-> oifcfg delif -global eth0
td1-> oifcfg delif -global eth1

重新新增

td1-> oifcfg setif -global eth0/10.194.128.0:public
td1-> oifcfg setif -global eth1/10.10.1.0:cluster_interconnect

4.更新註冊到OCR中的vip配置(root使用者)

[root@td1 ~]# crs_register -update ora.td1.vip -o oi=eth0,ov=10.194.128.147,on=255.255.255.0
[root@td1 ~]# crs_register -update ora.td2.vip -o oi=eth0,ov=10.194.128.148,on=255.255.255.0

或者使用(root使用者)

[root@td1 ~]# srvctl modify nodeapps -n td1 -A 10.194.128.147/255.255.255.0/eth0
[root@td1 ~]# srvctl modify nodeapps -n td2 -A 10.194.128.148/255.255.255.0/eth0

5.如果你使用了ocfs，修改ocfs配置檔案(/etc/ocfs/cluster.conf),驗證修改後是否可用
6.修改監聽listener配置檔案
7.啟動叢集各節點資源並驗證

td1-> crs_start –all

登陸資料庫，檢驗內連線是否生效。

SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— —————————-
eth1 10.10.1.145 NO Oracle Cluster Repository

<三>.叢集中節點的刪除/新增
    同9i的節點刪除/新增相比，10g對節點的新增和刪除相對來說略顯麻煩，但操作起來更加規範。
    因為叢集件的存在，需呼叫一系列介面命令將資源從OCR中新增/刪除，本文不再對該案例做詳細描述，具體參見oracle官方聯機文件RAC部分–Adding and Deleting Nodes and Instances on UNIX-Based Systems.

<四>.升級與遷移
    RAC的遷移與升級並不比單例項複雜多少。對於一個rac新手來說，在思想上也無需覺得這是個很龐雜的事情，當然前提是你有足夠的單例項方面的基礎知識並對此深刻理解。
    比如，利用rman備份，我們可以方便的將一個執行在單節點的例項遷移到rac環境下。需要做的重點，僅僅是遷移資料庫(你可以想象成是單例項對單例項)，然後編輯引數檔案，新增其他節點啟動db所必要的redo和undo，並註冊資料庫資源到叢集中以便管理。
    如果你的遷移或升級有停機時間的限制，那大部分情況下重點的問題並不在於被操作物件是RAC架構，而在於如何制定你的MAA策略。比如你需要運用一些表空間傳輸或者高階複製/流等方面的特性來壓縮停機時間，這也許因為是RAC架構而增加了整個施工的難度，但很多時候問題的重點並不在於此。
    接下來提供一個9I RAC同機靜默升級到 10G RAC的案例,詳細可參見我的一篇blog http://www.easyora.net/blog/9i_rac_upgrade_10g_rac.html

<五>.高可用架構:RAC+DG
    應該說，rac+dg企業級的架構在高可用和災備方面來說還是有相當大的市場。
    在搭建與管理方面，rac(主)+DG(備)的過程與單例項的主備也無太大異同。需要注意以下方面(但不限於以下方面):
1.log gap的檢測問題
    注意正確配置fal_server與fal_clicent引數，尤其是對於rac主庫歸檔到各自節點上的情況下,standby端gap server需要將每個主庫節點都涵蓋進去。
2.switchover/failover注意事項
    做任何切換的時候，需要將rac端只保留一個alive的例項，其餘例項關閉後，切換步驟跟單節點dg基本一致。
3.standby logfile問題
    如果採用LGWR傳輸日誌，需要備庫端新增standby logfile日誌。需要注意新增的standby logfile的thread要與主庫一致。如果你的主庫節點有3個例項，那需要新增3大組與rac主庫相同thread號的備用日誌，每個thread至少2組日誌即可。

六、RAC監控優化

1.思路及等待事件說明

  鑑於RAC體系的複雜性，RAC的優化比單例項的優化給我們提出了更高的難度和要求。大部分情況下，單例項上的優化方法在RAC結構下同樣適用。

  RAC優化的2個核心問題:

(1).減少shared pool的壓力:減少對資料字典的爭用，減少硬解析。

  因為row cache/library cache是全域性的，頻繁的資料字典爭用/硬解析在RAC環境下會造成比單例項更嚴重的效能後果。

(2).減少因Cache fusion帶來的全域性塊傳輸和爭用

  頻繁的Cache fusion會帶來一系列資料塊上的全域性爭用。如何減少邏輯讀，減少資料在例項之間共享傳輸，是RAC體系對應用設計和部署的新要求

Cache fusion效能是影響RAC系統效能的一個極為重要的方面。Avg global cache cr block receive time和avg global cache current block receive time是cache fusion的兩個重要指標，以下是oracle給出的這兩個指標的閾值情況:

Name	Lower Bound	Typical	Upper Bound
Avg global cache cr block receive time(ms)	0.3	4	12
Avg global cache current block receive time(ms)	0.3	8	30

RAC下的全域性等待事件:

SQL>select * from v$event_name where NAME like ‘gc%’ and WAIT_CLASS=’Cluster’;

10G R2下有40多個非空閒的全域性等待時間，最常見的值得引起注意的等待事件如下：

gc current/cr request

該等待事件表示資源從遠端例項讀取到本地例項所花費的時間。出現該事件並不能說明什麼問題，如果等待時間過長，可能表示內聯網路存在問題或者有嚴重的塊爭用。

gc buffer busy

buffer busy waits在全域性上的延伸。出現該等待時間一般可能是塊的爭用問題。

Enquenue類

RAC中，常見的Enquenue有enq: HW – contention/ enq: TX - index contention/enq等，在跨節點高併發的insert環境中很容易出現。

  諸如gc current-2way/3way.gc current/cr grant等事件，這些事件只是提供了塊傳輸和訊息傳輸方面的細節或是結果，一般情況下無需太投入關注。

2.效能診斷

  效能上的調整很難給出一個定式，但指導思想上可以實現很大方面的統一。

  AWR/ASH等報告可以作為RAC系統中一個強有力的效能採集和診斷工具。同單例項的報告相比，AWR中的RAC Statistics部分給我們提供了詳細的GES、GCS效能取樣，結合全域性等待事件，定位叢集問題上的症狀。

在RAC結構下，Segment Statistics部分是我們更加需要注意的地方。如果你還是習慣使用STATSPACK來進行效能採集，建議至少將收集級別設定為7。該部分為我們提供了詳細的Segment級別的活動情況，有助於我們定位全域性的HOT table /HOT index，分析全域性資源排隊爭用的根源。

  要重視DBA_HIS開頭的一系列檢視的作用，這將幫我們將問題定位的更加細化，甚至定位到SQL級別。糟糕的SQL效率拖垮系統效能的案例比比皆是，這在RAC中往往更加常見。dba_hist_active_sess_history 可以作為很好的切入點，例如通過關聯dba_hist_sqltext獲得執行文字，通過關聯dba_hist_sql_plan獲得執行計劃樹等，有時候將直接找到造成等待事件的元凶。

RAC中常見的爭用和解決方法：

① Sequence and index contention

  Sequence是RAC中容易引起爭用的一個地方,尤其是以sequence作索引，在高併發的多節點insert情況下極易引起索引塊的爭用以及CR副本的跨例項傳輸。
需要儘量增大Sequence的cache值並設定序列為noorder。

② undo block considerations

  RAC下CR的構造比單例項成本要高，如果一個block中的活動事務分佈在幾個例項上，需要將幾個例項上的undo合併構造所需要的CR，尤其是高併發的有索引鍵的插入，容易造成undo block的爭用。

儘量使用小事務處理。

③ HW considerations

  跨節點的高併發insert會造成高水位線的爭用，採用更大的extent/採用ASSM和分割槽技術能減緩這一爭用。

④ Hot Block

  全域性熱點塊問題對RAC系統的影響巨大，儘量減少塊跨例項的併發更改,適當採用分割槽可以緩解該爭用。

  一個良好的應用設計是RAC發揮功力的重要前提，根據不同的節點部署不同的應用，能有效的減少全域性資源的爭用，對RAC效能的穩定也相當重要。

---

---

服務硬體：指提供計算服務的硬體，比如 PC 機、PC 伺服器。

服務實體：服務實體通常指服務軟體和服務硬體。

節點（node）：執行 Heartbeat 程式的一個獨立主機稱為節點，節點是 HA 的核心組成部分，每個節點上執行著作業系統和Heartbeat 軟體服務。

資源（resource）：資源是一個節點可以控制的實體，當節點發生故障時，這些資源能夠被其他節點接管。如： 磁碟分割槽、檔案系統、IP 地址、應用程式服務、共享儲存

事件（event）：事件也就是叢集中可能發生的事情，例如節點系統故障、網路連通故障、網路卡故障和應用程式故障等。這些事件都會導致節點的資源發生轉移，HA 的測試也是基於這些事件進行的。

叢集（cluster）就是一組計算機，它們作為一個整體向使用者提供一組網路資源，這些單個的計算機系統就是叢集的節點（node）。叢集提供了以下關鍵的特性。

(一) 可擴充套件性。叢集的效能不限於單一的服務實體，新的服務實體可以動態的加入到叢集，從而增強叢集的效能。

(二) 高可用性。叢集通過服務實體冗餘使客戶端免於輕易遭遇到“out of service”警告。當一臺節點伺服器發生故障的時候，這臺伺服器上所執行的應用程式將在另一節點伺服器上被自動接管。消除單點故障對於增強資料可用性、可達性和可靠性是非常重要的。

(三) 負載均衡。負載均衡能把任務比較均勻的分佈到叢集環境下的計算和網路資源，以便提高資料吞吐量。

(四) 錯誤恢復。如果叢集中的某一臺伺服器由於故障或者維護需要而無法使用，資源和應用程式將轉移到可用的叢集節點上。這種由於某個節點中的資源不能工作，另一個可用節點中的資源能夠透明的接管並繼續完成任務的過程叫做錯誤恢復。

分散式與叢集的聯絡與區別如下：

(一) 分散式是指將不同的業務分佈在不同的地方。

(二) 而叢集指的是將幾臺伺服器集中在一起，實現同一業務。

(三) 分散式的每一個節點，都可以做叢集，而叢集並不一定就是分散式的。而分散式，從狹義上理解，也與叢集差不多，但是它的組織比較鬆散，不像叢集，有一定組織性，一臺伺服器宕了，其他的伺服器可以頂上來。分散式的每一個節點，都完成不同的業務，一個節點宕了，這個業務就不可訪問了。

叢集主要分成三大類：

HA：高可用叢集（High Availability Cluster）。

LBC：負載均衡叢集/負載均衡系統（Load Balance Cluster）

HPC：科學計算叢集（High Performance Computing Cluster）/高效能運算（High Performance Computing）叢集。

隨著經濟的高速發展，企業規模的迅猛擴張，企業使用者的數量、資料量的爆炸式增長，對資料庫提出了嚴峻的考驗。對於所有的資料庫而言，除了記錄正確的處理結果之外，還面臨著以下幾方面的挑戰。

• l  如何提高處理速度，實現資料庫的均衡負載。
• l  如何保證資料庫的可用性、資料安全性、以及如何實現資料叢集可擴性。
• l  怎麼綜合解決這些問題成為眾多企業關注的焦點。

在資料庫上，組建叢集也是同樣的道理，主要有以下幾個原因：

(一) 伴隨著企業的成長，業務量提高，資料庫的訪問量和資料量快速增長，其處理能力和計算速度也相應增大，使得單一的裝置根本無法承擔。

(二) 在以上情況下，若扔掉現有裝置，做大量的硬體升級，勢必造成現有資源的浪費，而且下一次業務量提升時，又將面臨再一次硬體升級的高額投入。於是，人們希望通過幾箇中小型伺服器組建叢集，實現資料庫的負載均衡及持續擴充套件；在需要更高資料庫處理速度時，只要簡單的增加資料庫伺服器就可以得到擴充套件。

(三) 資料庫作為資訊系統的核心，起著非常重要的作用，單一裝置根本無法保證系統的下持續執行，若發生系統故障，將嚴重影響系統的正常執行，甚至帶來巨大的經濟損失。於是，人們希望通過組建資料庫叢集，實現資料庫的高可用，當某節點發生故障時，系統會自動檢測並轉移故障節點的應用，保證資料庫的持續工作。

(四) 企業的資料庫儲存著企業的重要資訊，一些核心資料甚至關係著企業的命脈，單一裝置根本無法保證資料庫的安全性，一旦發生丟失，很難再找回來。於是，人們希望通過組建資料庫叢集，實現資料集的冗餘，通過備份資料來保證安全性。

資料庫叢集技術是將多臺伺服器聯合起來組成叢集來實現綜合效能優於單個大型伺服器的技術，這種技術不但能滿足應用的需要，而且大幅度的節約了投資成本。資料庫叢集技術分屬兩類體系：基於資料庫引擎的叢集技術和基於資料庫閘道器（中介軟體）的叢集技術。在資料庫叢集產品方面，其中主要包括基於資料庫引擎的叢集技術的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基於資料庫閘道器（中介軟體）的叢集技術的 ICX-UDS 等產品。

一般來講，資料庫叢集軟體側重的方向和試圖解決的問題劃分為三大類：

• l  負載均衡叢集（Load Balance Cluster，LBC）側重於資料庫的橫向擴充套件，提升資料庫的效能。
• l  高可用性叢集（High Availability Cluster，HAC）側重保證資料庫應用持續不斷。大部分的資料庫叢集側重與此。
• l  高安全性叢集（High Security Cluster，HSC）側重於容災。

只有 Oracle RAC 能實現以上三方面

(一) Oracle RAC：

其架構的最大特點是共享儲存架構（Shared-storage），整個 RAC 叢集是建立在一個共享的儲存裝置之上的，節點之間採用高速網路互聯。OracleRAC 提供了非常好的高可用特性，比如負載均衡和應用透明切塊（TAF），其最大的優勢在於對應用完全透明，應用無需修改便可切換到RAC 叢集。但是RAC 的可擴充套件能力有限，首先因為整個叢集都依賴於底層的共享儲存，所以共享儲存的 I/O 能力和可用性決定了整個叢集的可以提供的能力，對於 I/O 密集型的應用，這樣的機制決定後續擴容只能是 Scale up（向上擴充套件）型別，對於硬體成本、開發人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構中，採用 ASM 來整合多個儲存裝置的能力，使得 RAC 底層的共享儲存裝置具備線性擴充套件的能力，整個叢集不再依賴於大型儲存的處理能力和可用性。

RAC 的另外一個問題是，隨著節點數的不斷增加，節點間通訊的成本也會隨之增加，當到某個限度時，增加節點可能不會再帶來效能上的提高，甚至可能造成效能下降。這個問題的主要原因是 Oracle RAC 對應用透明，應用可以連線叢集中的任意節點進行處理，當不同節點上的應用爭用資源時，RAC 節點間的通訊開銷會嚴重影響叢集的處理能力。所以對於使用 ORACLE RAC 有以下兩個建議：

• l  節點間通訊使用高速網際網路絡；
• l  儘可能將不同的應用分佈在不同的節點上。

基於這個原因，Oracle RAC 通常在 DSS 環境（決策支援系統Decision Support System ，簡稱DSS)中可以做到很好的擴充套件性，因為 DSS 環境很容易將不同的任務分佈在不同計算節點上，而對於 OLTP 應用（On-Line Transaction Processing聯機事務處理系統），Oracle RAC 更多情況下用來提高可用性，而不是為了提高擴充套件性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 完全不同，它採用 無共享架構Shared nothing（shared nothing architecture）。整個叢集由管理節點(ndb_mgmd)，處理節點(mysqld)和儲存節點(ndbd)組 成，不存在一個共享的儲存裝置。MySQL cluster 主要利用了 NDB 儲存引擎來實現，NDB 儲存引擎是一個記憶體式儲存引擎，要求資料必須全部載入到記憶體之中。資料被自動分佈在叢集中的不同存 儲節點上，每個儲存節點只儲存完整資料的一個分片(fragment)。同時，使用者可以設定同一份資料儲存在多個不同的儲存節點上，以保證單點故障不會造 成資料丟失。MySQL cluster 主要由 3 各部分組成：

• l  SQL 伺服器節點
• l  NDB 資料儲存節點
• l  監控和管理節點

這樣的分層也是與 MySQL 本身把 SQL 處理和儲存分開的架構相關係的。MySQL cluster 的優點在於其是一個分散式的資料庫叢集，處理節點和儲存節點都可以線性增加，整個叢集沒有單點故障，可用性和擴充套件性都可以做到很高，更適合 OLTP 應用。但是它的問題在於：

• l   NDB（“NDB” 是一種“記憶體中”的儲存引擎，它具有可用性高和資料一致性好的特點。） 儲存引擎必須要求資料全部載入到記憶體之中，限制比較大，但是目前 NDB 新版本對此做了改進，允許只在記憶體中加 載索引資料，資料可以儲存在磁碟上。
• l  目前的 MySQL cluster 的效能還不理想，因為資料是按照主鍵 hash 分佈到不同的儲存節點上，如果應用不是通過主鍵去獲取資料的話，必須在所有的儲存節點上掃描， 返回結果到處理節點上去處理。而且，寫操作需要同時寫多份資料到不同的儲存節點上，對節點間的網路要求很高。

雖然 MySQL cluster 目前效能還不理想，但是 share nothing 的架構一定是未來的趨勢，Oracle 接手 MySQL之後，也在大力發展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。

(三) 分散式資料庫架構

MySQL 5 之後才有了資料表分割槽功能（Sharding）， Sharding 不是一個某個特定資料庫軟體附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴充套件(Scale Out，亦或橫向擴充套件、向外擴充套件)的解決方案，其主要目的是為突破單節點資料庫伺服器的 I/O 能力限制，解決資料庫擴充套件性問題。比如 Oracle 的 RAC 是採用共享儲存機制，對於 I/O 密集型的應用，瓶頸很容易落在儲存上，這樣的機制決定後續擴容只能是 Scale Up（向上擴充套件） 型別，對於硬體成本、開發人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源資料庫的擴充套件性解決方案，很少有聽說商業資料庫進行 Sharding 的。目前業界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。

Sharding 架構的優勢在於，叢集擴充套件能力很強，幾乎可以做到線性擴充套件，而且整個叢集的可用性也很高，部分節點故障，不會影響其他節點提供服務。Sharding 原理簡單，容易實現，是一種非常好的解決資料庫擴充套件性的方案。Sharding 並不是資料庫擴充套件方案的銀彈，也有其不適合的場景，比如處理事務型的應用它可能會造成應用架構複雜或者限制系統的功能，這也是它的缺陷所在。讀寫分離是架構分散式系統的一個重要思想。不少系統整體處理能力並不能同業務的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬體並不能一勞永逸。針對業務型別特點，需要從架構模式進行一系列的調整，比如業務模組的分割，資料庫的拆分等等。集中式和分散式是兩個對立的模式，不同行業的應用特點也決定了架構的思路。如網際網路行業中一些門戶站點，出於技術和成本等方面考慮，更多的採用開源的資料庫產品(如 MYSQL)，由於大部分是典型的讀多寫少的請求，因此為 MYSQL 及其複製技術大行其道提供了條件。而相對一些傳統密集交易型的行業，比如電信業、金融業等，考慮到單點處理能力和可靠性、穩定性等問題，可能更多的採用商用資料庫，比如DB2、Oracle 等。就資料庫層面來講，大部分傳統行業核心庫採用集中式的架構思路，採用高配的小型機做主機載體，因為資料庫本身和主機強大的處理能力，資料庫端一般能支撐業務的運轉，因此，Oracle 讀寫分離式的架構相對MYSQL 來講，相對會少。讀寫分離架構利用了資料庫的複製技術，將讀和 寫分佈在不同的處理節點上，從而達到提高可用性和擴充套件性的目的。最通常的做法是利用 MySQL Replication 技術，Master DB 承擔寫操作，將資料變化複製到多臺 Slave DB上，並承擔讀的操作。這種架構適合 read-intensive 型別的應用，通過增加 Slave DB 的數量，讀的效能可以線性增長。為了避免 Master DB 的單點故障，叢集一般都會採用兩臺 Master DB 做雙機熱備，所以整個叢集的讀和寫的可用性都非常高。除了 MySQL，Oracle 從 11g 開始提供 Active Standby 的功能，也具備了實現讀寫分離架構的基礎。讀寫分離架構的缺陷在於，不管是 Master 還是 Slave，每個節點都必須儲存完整的資料，如 果在資料量很大的情況下，叢集的擴充套件能力還是受限於單個節點的儲存能力，而且對於 Write-intensive 型別的應用，讀寫分離架構並不適合。

採用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 採用日誌複製軟體實現實時同步； Writer DB 負責交易相關的實時查詢和事務處理，Reader DB 負責只讀接入，處理一些非實時的交易明細,報表類的彙總查詢等。同時，為了滿足高可用性和擴充套件性等要求，對讀寫端適當做外延，比如 Writer DB 採用 HA 或者 RAC 的架構模式，目前，除了資料庫廠商的 叢集產品以外，解決資料庫擴充套件能力的方法主要有兩個：資料分片和讀寫分離。資料分片(Sharding)的原理就是將資料做水平切分，類似於 hash 分割槽 的原理，通過應用架構解決訪問路由和Reader DB 可以採用多套，通過負載均衡或者業務分離的方式，有效分擔讀庫的壓力。

對於 Shared-nothing 的資料庫架構模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負責業務查詢，但並不代表資料庫在功能上是隻讀的。只讀是從應用角度出發，為了保證資料一致和衝突考慮，因為查詢業務模組可能需要涉及一些中間處理，如果需要在資料庫裡面處理(取決與應用需求和設計)，所以Reader DB 在功能上仍然需要可寫。下面談一下資料同步的技術選型問題：

能實現資料實時同步的技術很多，基於 OS 層(例如 VERITAS VVR)，基於儲存複製(中高階儲存大多都支援)，基於應用分發或者基於資料庫層的技術。因為資料同步可能並不是單一的 DB 整庫同步，會涉及到業務資料選擇以及多源整合等問題，因此 OS 複製和儲存複製多數情況並不適合做讀寫分離的技術首選。基於日誌的 Oracle 複製技術，Oracle 自身元件可以實現，同時也有成熟的商業軟體。選商業的獨立產品還是 Oracle 自身的元件功能，這取決於多方面的因素。比如團隊的相應技術運維能力、專案投入成本、業務系統的負載程度等。

採用 Oracle 自身元件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來說，Stream 最靈活，但最不穩定，11g Physical Standby 支援恢復與只讀並行，但由於並不是日誌的邏輯應用機制，在讀寫分離的場景中最為侷限。如果技術團隊對相關技術掌握足夠充分，而選型方案的處理能力又能支撐資料同步的要求，採用 Oracle 自身的元件完全可行。選擇商業化的產品，更多出於穩定性、處理能力等考慮。市面上成熟的 Oracle 複製軟體也無外乎幾種，無論是老牌的 Shareplex，還是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標。隨著 GoldenGate 被 Oracle 收購和推廣，個人認為 GoldenGate 在容災、資料分發和同步方面將大行其道。當然，架構好一個可靠的分散式讀寫分離的系統，還需要應用上做大量設計，不在本文討論範圍內。

(四)  CAP 和 BASE 理論

分散式領域 CAP 理論：

• l  Consistency(一致性), 資料一致更新，所有資料變動都是同步的
• l  Availability(可用性), 好的響應效能
• l  Partition tolerance(分割槽容錯性) 可靠性

定理：任何分散式系統只可同時滿足二點，沒法三者兼顧。

忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分散式系統，而是應該進行取捨。

關聯式資料庫的 ACID 模型擁有 高一致性 + 可用性 很難進行分割槽：

• l  Atomicity 原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。
• l  Consistency 一致性. 在事務開始或結束時，資料庫應該在一致狀態。
• l  Isolation 隔離層. 事務將假定只有它自己在運算元據庫，彼此不知曉。
• l  Durability. 一旦事務完成，就不能返回。

(五)  跨資料庫事務

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統關係型資料庫要想實現一個分散式資料庫叢集非常困難，關係型資料庫的擴充套件能力十分有限。而近年來不斷髮展壯大的 NoSQL（非關係型的資料庫）運動，就是通過犧牲強一致性，採用 BASE 模型，用最終一致性的思想來設計分散式系統，從而使得系統可以達到很高的可用性和擴充套件性。那麼，有沒有可能實現一套分散式資料庫叢集，既保證可用性和一致性，又可以提供很好的擴充套件能力呢？

BASE 思想的主要實現有按功能劃分資料庫 sharding 碎片BASE 思想主要強調基本的可用性，如果你需要 High 可用性，也就是純粹的高效能，那麼就要以一致性或容錯性為犧牲，BASE 思想的方案在效能上還是有潛力可挖的。

• l  共同點：都是關聯式資料庫 SQL 以外的可選方案，邏輯隨著資料分佈，任何模型都可以自己持久化，將資料處理和資料儲存分離，將讀和寫分離，儲存可以是非同步或同步，取決於對一致性的要求程度。
• l  不同點：NOSQL 之類的 Key-Value 儲存產品是和關聯式資料庫頭碰頭的產品 BOX，可以適合非 Java 如 PHP RUBY等領域，是一種可以拿來就用的產品，而領域模型 + 分散式快取 + 儲存是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

目前，已經有很多分散式資料庫的產品，但是絕大部分是面向 DSS 型別的應用，因為相比較 OLTP 應用，DSS 應用更容易做到分散式擴充套件，比如基於 PostgreSQL 發展的 Greenplum，就很好的解決了可用性和擴充套件性的問題，並且提供了很強大的平行計算能力。對於 OLTP 應用，業務特點決定其要求：高可用性，一致性， 響應時間短，支援事務和 join 等等。資料庫和 NoSQL當越來越多的 NoSQL 產品湧現出來，它們具備很多關係型資料庫所不具備的特性，在可用性和擴充套件性方面都可以做到很好。

第一，NoSQL 的應用場景非常侷限，某個型別的 NoSQL 僅僅針對特定型別的應用場景而設計。而關係型資料庫則要通用的多，使用 NoSQL 必須搞清楚自己的應用場景是否適合。

第二，利用關係型資料庫配合應用架構， 比如 Sharding 和讀寫分離技術，同樣可以搭建出具備高可用和擴充套件性的分散式資料庫叢集。

第三，關係型資料庫廠商依然很強大，全世界有大量的 使用者，需求必然會推動新的產品問世。

第四，硬體的發展日新月異，比如快閃記憶體的技術的不斷成熟，未來快閃記憶體可以作為磁碟與記憶體之間的 cache，或者完 全替代磁碟。而記憶體價格越來越低，容量越來越大，In-memory cache 或 database 的應用越來越廣泛，可以給應用帶來數量級的效能提升。資料庫面臨的 IO 問題將被極大改善。

1 RAC（Real Application Clusters）

                       

多個Oracle伺服器組成一個共享的Cache，而這些Oracle伺服器共享一個基於網路的儲存。這個系統可以容忍單機/或是多機失敗。不過系統內部的多個節點需要高速網路互連，基本上也就是要全部東西放在在一個機房內，或者說一個資料中心內。如果機房出故障，比如網路不通，那就壞了。所以僅僅用RAC還是滿足不了一般網際網路公司的重要業務的需要，重要業務需要多機房來容忍單個機房的事故。

2 Data Guard.（最主要的功能是冗災）

 

Data Guard這個方案就適合多機房的。某機房一個production的資料庫，另外其他機房部署standby的資料庫。Standby資料庫分物理的和邏輯的。物理的standby資料庫主要用於production失敗後做切換。而邏輯的standby資料庫則在平時可以分擔production資料庫的讀負載。

3 MAA

 

MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結合，來提供最高的可用性。每個機房內部署RAC叢集，多個機房間用Data Guard同步。

共享儲存檔案系統（NFS），或甚至叢集檔案系統（如：OCFS2）主要被用於儲存區域網路（所有節點直接訪問共享檔案系統上儲存器），這就使得節點失效而不影響來自其他節點對檔案系統的訪問，通常，共享磁碟檔案系統用於高可用叢集。

Oracle RAC的核心是共享磁碟子系統，叢集中所有節點必須能夠訪問所有資料、重做日誌檔案、控制檔案和引數檔案，資料磁碟必須是全域性可用的，允許所有節點訪問資料庫，每個節點有它自己的重做日誌和控制檔案，但是其他節點必須能夠訪問它們以便在那個節點出現系統故障時能夠恢復。

Oracle RAC 執行於叢集之上，為 Oracle 資料庫提供了最高階別的可用性、可伸縮性和低成本計算能力。如果叢集內的一個節點發生故障，Oracle 將可以繼續在其餘的節點上執行。Oracle 的主要創新是一項稱為快取記憶體合併的技術。快取記憶體合併使得叢集中的節點可以通過高速叢集互聯高效地同步其記憶體快取記憶體，從而最大限度地低降低磁碟 I/O。快取記憶體最重要的優勢在於它能夠使叢集中所有節點的磁碟共享對所有資料的訪問。資料無需在節點間進行分割槽。Oracle 是唯一提供具備這一能力的開放系統資料庫的廠商。其它聲稱可以執行在叢集上的資料庫軟體需要對資料庫資料進行分割槽，顯得不切實際。企業網格是未來的資料中心，構建於由標準化商用元件構成的大型配置之上，其中包括：處理器、網路和儲存器。Oracle RAC 的快取記憶體合併技術提供了最高等級的可用性和可伸縮性。Oracle 資料庫 10g 和 OracleRAC 10g 顯著降低了運營成本，增強了靈活性，從而賦予了系統更卓越的適應性、前瞻性和靈活性。動態提供節點、儲存器、CPU 和記憶體可以在實現所需服務級別的同時，通過提高的利用率不斷降低成本。

Oracle RAC 10g 在 Oracle 資料庫 10g 執行的所有平臺上提供了一個完整整合的叢集件管理解決方案。這一叢集件功能包括叢集連線、訊息處理服務和鎖定、叢集控制和恢復，以及一個工作負載管理框架（將在下文探討）。Oracle RAC 10g 的整合叢集件管理具有以下優勢：

(一) 成本低。Oracle 免費提供這一功能。

(二) 單一廠商支援。消除了相互推諉的問題。

(三) 安裝、配置和持續維護更簡單。Oracle RAC 10g 叢集件使用標準 Oracle 資料庫管理工具進行安裝、配置和維護。這一過程無須其它的整合步驟。

(四) 所有平臺，質量始終如一。與第三方產品相比，Oracle 對新軟體版本進行了更嚴格的測試。

(五) 所有平臺，功能始終如一。例如，一些第三方叢集件產品限制了叢集內可以支援的節點的數量。藉助Oracle RAC 10g，所有平臺可以支援多達 64 個節點。使用者還可以在所有平臺上獲得一致的響應體驗，從而有效解決了高可用性挑戰，包括伺服器節點故障、互連故障以及 I/O 隔離現象等。

(六) 支援高階功能。這包括整合監視和通知功能，從而在發生故障時，在資料庫和應用層之間實現快速協調的恢復。

RAC 是 Oracle 資料庫的一個群集解決方案，是有著兩個或者兩個以上的資料庫節點協調運作能力的。如下圖所示的 RAC 結構圖：

 

叢集管理器（Cluster Manager）在叢集系統中對其他各個模組進行整合，通過高速的內連線來提供群集節點之間的通訊。各節點之間內連線使用心跳線互聯，心跳線上的資訊功能確定群集邏輯上的節點成員資訊和節點更新情況，以及節點在某個時間點的執行狀態，保證群集系統正常執行。通訊層管理節點之間的通訊。它的職責是配置，互聯群集中節點資訊，在群集管理器中使用由心跳機制產生的資訊，由通訊層負責傳輸，確保資訊的正確到達。還有一些群集監視程式不斷驗證系統的不同領域執行狀況。例如，心跳監測不斷驗證的心跳機制的運作是否良好。在一個應用環境當中，所有的伺服器使用和管理同一個資料庫，目的是分散每一臺伺服器的工作量。硬體上至少需要兩臺以上的伺服器，而且還需要一個共享儲存裝置；同時還需要兩類軟體，一類是叢集軟體，另外一類就是 Oracle 資料庫中的 RAC 元件。同時所有伺服器上的 OS 都應該是同一類 OS，根據負載均衡的配置策略，當一個客戶端傳送請求到某一臺服務的 listener 後，這臺伺服器根據負載均衡策略，會把請求傳送給本機的 RAC元件處理，也可能會傳送給另外一臺伺服器的 RAC 元件處理，處理完請求後，RAC 會通過群集軟體來訪問共享儲存裝置。邏輯結構上看，每一個參加群集的節點有一個獨立的例項，這些例項訪問同一個資料庫。節點之間通過叢集軟體的通訊層（Communication Layer）來進行通訊。同時為了減少 I/O 的消耗，存在一個全域性快取服務，因此每一個資料庫的例項，都保留了一份相同的資料庫 cache。RAC 中的特點如下：

• l  ? 每一個節點的例項都有自己的 SGA；
• l  ? 每一個節點的例項都有自己的後臺程式
• l  ? 每一個節點的實力都有自己的 redo logs
• l  ? 每一個節點的例項都有自己的 undo 表空間
• l  ? 所有節點都共享一份 datafiles 和 controlfiles

在 Oracle9i 之前，RAC 稱為 OPS（Oracle Parallel Server）。RAC 與 OPS 之間的一個較大區別是，RAC 採用了Cache Fusion（高快取合併）技術，節點已經取出的資料塊更新後沒有寫入磁碟前，可以被另外一個節點更新，然後以最後的版本寫入磁碟。在 OPS 中，節點間的資料請求需要先將資料寫入磁碟，然後發出請求的節點才可以讀取該資料。使用 Cache Fusion 時，RAC 的各個節點間資料緩衝區通過高速、低延遲的內部網路進行資料塊的傳輸。下圖是一個典型的 RAC 對外服務的示意圖，一個 Oracle RAC Cluster 包含了如下的部分

 

1. 叢集的節點（Cluster node）——2 個到 N 個節點或者主機執行 Oracle Database Server。
2. 私有網路（Network Interconnect）——RAC 之間需要一個高速互聯的私有網路來處理通訊和 Cache Fusion。
3. 共享儲存（shared Storage）——RAC 需要共享儲存裝置讓所有的節點都可以訪問資料檔案。
4. 對外服務的網路（Production Network）——RAC 對外服務的網路。客戶端和應用都通過這個網路來訪問。

Oracle RAC 有一些自己獨特的後臺程式，在單一例項中不發揮配置作用。如下圖所示，定義了一些 RAC 執行的後臺程式。這些後臺程式的功能描述如下。

 

（1）LMS（Global cache service processes 全域性快取服務程式）程式主要用來管理叢集內資料塊的訪問，並在不同例項的 Buffer Cache 中傳輸資料塊映象。直接從控制的例項的快取複製資料塊，然後傳送一個副本到請求的例項上。並保證在所有例項的 Buffer Cache 中一個資料塊的映象只能出現一次。LMS 程式靠著在例項中傳遞訊息來協調資料塊的訪問，當一個例項請求資料塊時，該例項的 LMD 程式發出一個資料塊資源的請求，該請求指向主資料塊的例項的 LMD 程式，主例項的 LMD 程式和正在使用的例項的 LMD 程式釋放該資源，這時擁有該資源的例項的 LMS 程式會建立一個資料塊映象的一致性讀然後把該資料塊傳遞到請求該資源的例項的BUFFER CACHE 中。LMS 程式保證了在每一時刻只能允許一個例項去更新資料塊，並負責保持該資料塊的映象記錄（包含更新資料塊的狀態 FLAG)。RAC 提供了 10 個 LMS 程式（0~9），該程式數量隨著節點間的訊息傳遞的資料的增加而增加。（2）LMON（Lock Monitor Process，鎖監控程式）是全域性佇列服務監控器，各個例項的 LMON 程式會定期通訊，以檢查叢集中各個節點的健康狀況，當某個節點出現故障時，負責叢集重構、GRD 恢復等操作，它提供的服務叫做 Cluster Group Service（CGS）。

LMON 主要藉助兩種心跳機制來完成健康檢查。

(一) 節點間的網路心跳（Network Heartbeat）：可以想象成節點間定時的傳送 ping 包檢測節點狀態，如果能在規定時間內收到回應，就認為對方狀態正常。

(二) 通過控制檔案的磁碟心跳（controlfile heartbeat）：每個節點的 CKPT 程式每隔 3 秒鐘更新一次控制檔案的資料塊，這個資料塊叫做 Checkpoint Progress Record，控制檔案是共享的，所以例項間可以互相檢查對方是否及時更新來判斷。

(三) LMD（the global enqueue service daemon，鎖管理守護程式）是一個後臺程式，也被稱為全域性的佇列服務守護程式，因為負責對資源的管理要求來控制訪問塊和全域性佇列。在每一個例項的內部，LMD 程式管理輸入的遠端資源請求（即來自叢集中其他例項的鎖請求）。此外，它還負責死鎖檢查和監控轉換超時。

(四) LCK（the lock process，鎖程式）管理非快取融合，鎖請求是本地的資源請求。LCK 程式管理共享資源的例項的資源請求和跨例項呼叫操作。在恢復過程中它建立一個無效鎖元素的列表，並驗證鎖的元素。由於處理過程中的 LMS 鎖管理的首要職能，只有一個單一的 LCK 程式存在每個例項中。

(五) DIAG（the diagnosability daemon，診斷守護程式）負責捕獲 RAC 環境中程式失敗的相關資訊。並將跟蹤資訊寫出用於失敗分析，DIAG 產生的資訊在與 Oracle Support 技術合作來尋找導致失敗的原因方面是非常有用的。每個例項僅需要一個 DIAG 程式。

(六) GSD（the global service daemon，全域性服務程式）與 RAC 的管理工具 dbca、srvctl、oem 進行互動，用來完成例項的啟動關閉等管理事務。為了保證這些管理工具執行正常必須在所有的節點上先start gsd，並且一個 GSD 程式支援在一個節點的多個 rac.gsd 程式位ORACLEHOME/bin目錄下，其log檔案為ORACLEHOME/bin目錄下，其log檔案為ORACLE_HOME/srvm/log/gsdaemon.log。GCS 和 GES 兩個程式負責通過全域性資源目錄（Global Resource Directory GRD）維護每個資料的檔案和快取塊的狀態資訊。當某個例項訪問資料並快取了資料之後，叢集中的其他例項也會獲得一個對應的塊映象，這樣其他例項在訪問這些資料是就不需要再去讀盤了，而是直接讀取 SGA 中的快取。GRD 存在於每個活動的 instance 的記憶體結構中，這個特點造成 RAC 環境的 SGA 相對於單例項資料庫系統的 SGA 要大。其他的程式和記憶體結構都跟單例項資料庫差別不大。

RAC 需要有共享儲存，獨立於例項之外的資訊，如上面提到的ocr 和 votedisk 以及資料檔案都存放在這個共享儲存裡的。有OCFS、OCFS2、RAW、NFS、ASM 等這樣的一些儲存方式。OCFS（Oracle Cluster File System） 和 OCFS2 就是一個檔案系統而已，和 NFS 一樣，提供一種叢集環境中的共享儲存的檔案系統。RAW 裸裝置也是一種儲存方式，是 oracle11g 之前的版本中 RAC 支援的儲存方式，在 Oralce9i 之前，OPS/RAC的支援只能使用這樣的方式，也就是把共享儲存對映到 RAW Device，然後把 Oracle 需要的資料選擇 RAW device儲存，但是 RAW 相對於檔案系統來說不直觀，不便於管理，而且 RAW Device 有數量的限制，RAW 顯然需要有新的方案來代替，這樣就有了 OCFS 這樣的檔案系統。當然，這只是 Oracle 自己的實現的集檔案系統而已，還有其他廠商提供的檔案系統可以作為儲存的選擇方案。ASM 只是資料庫儲存的方案而已，並不是 cluster 的方案，所以這裡 ASM 應該是區別於 RAW 和 OCFS/OCFS2同一級別的概念，RAW 和 OCFS/OCFS2 不僅可以作為資料庫儲存的方案，同時也可以作為 Clusterware 裡的儲存方案，是 CRS 裡需要的 storage，而 ASM 僅作為資料庫的儲存而已，嚴格來說僅是 RAC 中的一個節點應用（nodeapps）。ASM 對於 clusterware 安裝時需要的 ocr 和 votedisk 這兩項還不支援，畢竟 ASM 本身就需要一個例項，而 CRS 是完全在架構之外的，這也就是為什麼使用了 ASM 的方案，卻總還要加上 OCFS/OCFS2 和 RAW 其中的一個原因。各種 RAC 共享儲存方式的對比如下：

1. 叢集檔案系統——支援 windows 和 Linux 的 OCFS/OCFS2
2. AIX 下的 GPFS 等方式——優點是管理方便，表示也很直觀，但缺點是基於檔案系統管理軟體，又要經過 OS 的 cache 處理，效能上和穩定性上都有欠缺，所以不適合在生產環境下使用。可以支援 CRS 叢集軟體檔案和資料庫檔案。
3. RAW 裸裝置方式——通過硬體支援的共享儲存系統，直接用 RAW 裝置儲存，可以支援叢集軟體檔案和資料庫檔案。
4. 網路檔案系統（NFS）——通過 NFS 實現共享儲存，不過需要經過 Oracle 認證的 NFS 才行，可以支援CRS 叢集軟體檔案和資料庫檔案。
5. ASM——集合 RAW 方式 I/O 高效能和叢集檔案系統易管理等優點，Oracle10g 下推出的共享儲存方式，但是本身 ASM 就是需要 Oracle 的例項支援，所以 ASM 僅支援資料庫檔案，而不支援 CRS 檔案。

為了讓 RAC 中的所有例項能夠訪問資料庫，所有的 datafiles、control files、PFILE/Spfile 和 redo log files 必須儲存在共享磁碟上，並且要都能被所有節點同時訪問，就涉及到裸裝置和叢集檔案系統等。RAC database 在結構上與單例項的不同之處：至少為每個例項多配置一個 redo 執行緒，比如：兩個例項組成的叢集至少要 4 個 redo log group。每個例項兩個 redo group。另外要為每一個例項準備一個 UNDO 表空間。

1、redo 和 undo，每個例項在做資料庫的修改時誰用誰的 redo 和 undo 段，各自鎖定自己修改的資料，把不同例項的操作相對的獨立開就避免了資料不一致。後面就要考慮備份或者恢復時 redo log 和歸檔日誌在這種情況下的特殊考慮了。

2、記憶體和程式各個節點的例項都有自己的記憶體結構和程式結構.各節點之間結構是基本相同的.通過 Cache Fusion（快取融合）技術，RAC 在各個節點之間同步 SGA 中的快取資訊達到提高訪問速度的效果也保證了一致性。

RAC 工作原理和相關元件

      OracleRAC 是多個單例項在配置意義上的擴充套件，實現由兩個或者多個節點（例項）使用一個共同的共享資料庫（例如，一個資料庫同時安裝多個例項並開啟）。在這種情況下，每一個單獨的例項有它自己的 cpu 和實體記憶體，也有自己的 SGA 和後臺程式。和傳統的 oracle 例項相比，在系統全域性區（SYSTEM CLOBAL AREA,SGA）與後臺程式有著顯著的不同。最大的不同之處在於多了一個GRD,GRD記憶體塊主要是記錄此rac有多少個叢集資料庫與系統資源，同時也會記錄資料塊的相關資訊，因為在 rac 架構中，每個資料塊在每一個 SGA 中都有一份副本，而 rac 必須知道這些資料塊的位置，版本，分佈以及目前的狀態，這些資訊就存放在 GRD 中，但 GRD 只負責存放不負責管理，管理的責任則交給後臺程式 GCS 和 GES 來進行。Oracle 的多個例項訪問一個共同的共享資料庫。每個例項都有自己的 SGA、PGA 和後臺程式，這些後臺程式應該是熟悉的，因為在 RAC 配置中，每個例項將需要這些後臺程式執行支撐的。可以從以下幾個方面瞭解 RAC工作原理和執行機制。

(一) SCN

      SCN 是 Oracle 用來跟蹤資料庫內部變化發生先後順序的機制，可以把它想象成一個高精度的時鐘，每個 Redo日誌條目，Undo Data Block，Data Block 都會有 SCN 號。 Oracle 的Consistent-Read， Current-Read，Multiversion-Block 都是依賴 SCN 實現。在 RAC 中，有 GCS 負責全域性維護 SCN 的產生，預設用的是 Lamport SCN 生成演算法，該演算法大致原理是： 在所有節點間的通訊內容中都攜帶 SCN， 每個節點把接收到的 SCN 和本機的 SCN 對比，如果本機的 SCN 小，則調整本機的 SCN 和接收的一致，如果節點間通訊不多，還會主動地定期相互通報。 故即使節點處於 Idle 狀態，還是會有一些 Redo log 產生。 還有一個廣播演算法（Broadcast），這個演算法是在每個 Commit 操作之後，節點要想其他節點廣播 SCN，雖然這種方式會對系統造成一定的負載，但是確保每個節點在 Commit 之後都能立即檢視到 SCN.這兩種演算法各有優缺點，Lamport 雖然負載小，但是節點間會有延遲，廣播雖然有負載，但是沒有延遲。Oracle 10g RAC 預設選用的是 BroadCast 演算法，可以從 alert.log 日誌中看到相關資訊：Picked broadcast on commit scheme to generate SCNS

(二) RAC 的 GES/GCS 原理

       全域性佇列服務（GES）主要負責維護字典快取和庫快取的一致性。字典快取是例項的 SGA 內所儲存的對資料字典資訊的快取，用於高速訪問。由於該字典資訊儲存在記憶體中，因而在某個節點上對字典進行的修改（如DDL)必須立即被傳播至所有節點上的字典快取。GES 負責處理上述情況，並消除例項間出現的差異。處於同樣的原因，為了分析影響這些物件的 SQL 語句，資料庫內物件上的庫快取鎖會被去掉。這些鎖必須在例項間進行維護，而全域性佇列服務必須確保請求訪問相同物件的多個例項間不會出現死鎖。LMON、LCK 和 LMD 程式聯合工作來實現全域性佇列服務的功能。GES 是除了資料塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環境中調節節點間其他資源的重要服務。為了保證叢集中的例項的同步，兩個虛擬服務將被實現：全域性排隊服務（GES），它負責控制對鎖的訪問。

       全域性記憶體服務（GCS)，控制對資料塊的訪問。GES 是 分散式鎖管理器(DLM)的擴充套件，它是這樣一個機制，可以用來管理 oracle 並行伺服器的鎖和資料塊。在一個群集環境中，你需要限制對資料庫資源的訪問，這些資源在單 instance 資料庫中被 latches 或者 locks 來保護。比如說，在資料庫字典記憶體中的物件都被隱性鎖所保護，而在庫快取記憶體中的物件在被引用的時候，必須被 pin 所保護。在 RAC 群集中，這些物件代表了被全域性鎖所保護的資源。GES 是一個完整的 RAC 元件，它負責和群集中的例項全域性鎖進行溝通，每個資源有一個主節點例項，這個例項記錄了它當前的狀態。而且，資源的當前的狀態也記錄在所有對這個資源有興趣的例項上。GCS,是另一個 RAC 元件，負責協調不同例項間對資料塊的訪問。對這些資料塊的訪問以及跟新都記錄在全域性目錄中（GRD）,這個全域性目錄是一個虛擬的記憶體結構，在所有的例項中使用擴張。每個塊都有一個master例項，這個例項負責對GSD的訪問進行管理，GSD裡記錄了這個塊的當前狀態資訊。GCS 是 oracle 用來實施 Cache fusion 的機制。被 GCS 和 GES 管理的塊和鎖叫做資源。對這些資源的訪問必須在群集的多個例項中進行協調。這個協調在例項層面和資料庫層面都有發生。例項層次的資源協調叫做本地資源協調；資料庫層次的協調叫做全域性資源協調。

      本地資源協調的機制和單例項 oracle 的資源協調機制類似，包含有塊級別的訪問，空間管理，dictionary cache、library cache 管理，行級鎖，SCN 發生。全域性資源協調是針對 RAC 的，使用了 SGA 中額外的記憶體元件、演算法和後臺程式。GCS 和 GES 從設計上就是在對應用透明的情況下設計的。換一句話來說，你不需要因為資料庫是在 RAC上執行而修改應用,在單例項的資料庫上的並行機制在 RAC 上也是可靠地。

支援 GCS 和 GES 的後臺程式使用私網心跳來做例項之間的通訊。這個網路也被 Oracle 的 群集元件使用，也有可能被 群集檔案系統（比如 OCFS)所使用。GCS 和 GES 獨立於 Oracle 群集元件而執行。但是，GCS 和GES 依靠 這些群集元件獲得群集中每個例項的狀態。如果這些資訊不能從某個例項獲得，這個例項將被關閉。這個關閉操作的目的是保護資料庫的完整性，因為每個例項需要知道其他例項的情況，這樣可以更好的確定對資料庫的協調訪問。GES 控制資料庫中所有的 library cache 鎖和 dictionary cache 鎖。這些資源在單例項資料庫中是本地性的，但是到了 RAC 群集中變成了全域性資源。全域性鎖也被用來保護資料的結構，進行事務的管理。一般說來，事務和表鎖 在 RAC 環境或是 單例項環境中是一致的。

       Oracle 的各個層次使用相同的 GES 功能來獲得，轉化以及釋放資源。在資料庫啟動的時候，全域性佇列的個數將被自動計算。GES 使用後臺程式 LMD0 和 LCK0 來執行它的絕大多數活動。一般來說，各種程式和本地的 LMD0 後臺程式溝通來管理全域性資源。本地的 LMD0 後臺程式與 別的例項上的 LMD0 程式進行溝通。

      LCK0 後臺程式用來獲得整個例項需要的鎖。比如，LCK0 程式負責維護 dictionary cache 鎖。影子程式(服務程式） 與這些後臺程式通過 AST(非同步陷阱）訊息來通訊。非同步訊息被用來避免後臺程式的阻塞，這些後臺程式在等待遠端例項的的回覆的時候將阻塞。後臺程式也能 傳送 BAST(非同步鎖陷阱）來鎖定程式，這樣可以要求這些程式把當前的持有鎖置為較低階限制的模式。資源是記憶體結構，這些結構代表了資料庫中的元件，對這些元件的訪問必須為限制模式或者序列化模式。換一句話說，這個資源只能被一個程式或者一直例項並行訪問。如果這個資源當前是處於使用狀態，其他想訪問這個資源的程式必須在佇列中等待，直到資源變得可用。佇列是記憶體結構，它負責並行化對特殊資源的訪問。如果這些資源只被本地例項需求，那麼這個佇列可以本地來獲得，而且不需要協同。但是如果這個資源被遠端例項所請求，那麼本地佇列必須變成全球化。

      在單機環境下，Oracle 是執行在 OS Kernel 之上的。 OS Kernel 負責管理硬體裝置，並提供硬體訪問介面。Oracle 不會直接操作硬體，而是有 OS Kernel 代替它來完成對硬體的呼叫請求。在叢集環境下， 儲存裝置是共享的。OS Kernel 的設計都是針對單機的，只能控制單機上多個程式間的訪問。 如果還依賴 OS Kernel 的服務，就無法保證多個主機間的協調工作。 這時就需要引入額外的控制機制，在RAC 中，這個機制就是位於 Oracle 和 OS Kernel 之間的 Clusterware，它會在 OS Kernel 之前截獲請求，然後和其他結點上的 Clusterware 協商，最終完成上層的請求。在 Oracle 10G 之前，RAC 所需要的叢集件依賴與硬體廠商，比如 SUN,HP,Veritas. 從 Oracle 10.1版本中，Oracle推出了自己的叢集產品. Cluster Ready Service(CRS),從此 RAC 不在依賴與任何廠商的叢集軟體。 在 Oracle 10.2版本中，這個產品改名為：Oracle Clusterware。所以我們可以看出， 在整個 RAC 叢集中，實際上有 2 個叢集環境的存在，一個是由 Clusterware 軟體組成的叢集，另一個是由 Database 組成的叢集。

(一) Clusterware 的主要程式

a) CRSD——負責叢集的高可用操作，管理的 crs 資源包括資料庫、例項、監聽、虛擬 IP，ons，gds 或者其他，操作包括啟動、關閉、監控及故障切換。改程式由 root 使用者管理和啟動。crsd 如果有故障會導致系統重啟。

b) cssd，管理各節點的關係，用於節點間通訊，節點在加入或離開叢集時通知叢集。該程式由 oracle 使用者執行管理。發生故障時 cssd 也會自動重啟系統。

c) oprocd – 叢集程式管理 —Process monitor for the cluster. 用於保護共享資料 IO fencing。

d) 僅在沒有使用 vendor 的叢集軟體狀態下執行

e) evmd ：事件檢測程式，由 oracle 使用者執行管理

      Cluster Ready Service（CRS，叢集準備服務）是管理叢集內高可用操作的基本程式。Crs 管理的任何事物被稱之為資源，它們可以是一個資料庫、一個例項、一個監聽、一個虛擬 IP（VIP）地址、一個應用程式等等。CRS是根據儲存於 OCR 中的資源配置資訊來管理這些資源的。這包括啟動、關閉、監控及故障切換（start、stop、monitor 及 failover）操作。當一資源的狀態改變時，CRS 程式生成一個事件。當你安裝 RAC 時，CRS 程式監控Oracle 的例項、監聽等等，並在故障發生時自動啟動這些元件。預設情況下，CRS 程式會進行 5 次重啟操作，如果資源仍然無法啟動則不再嘗試。Event Management（EVM）：釋出 CRS 建立事件的後臺程式。Oracle Notification Service（ONS）：通訊的快速應用通知（FAN：Fast Application Notification）事件的釋出及訂閱服務。RACG：為 clusterware 進行功能擴充套件以支援 Oracle 的特定需求及複雜資源。它在 FAN 事件發生時執行伺服器端的呼叫指令碼（server callout script）Process Monitor Daemon（OPROCD）：此程式被鎖定在記憶體中，用於監控叢集（cluster）及提供 I/O 防護（I/Ofencing）。OPROCD 執行它的檢查，停止執行，且如果喚醒超過它所希望的間隔時，OPROCD 重置處理器及重啟節點。一個 OPROCD 故障將導致 Clusterware 重啟節點。

      Cluster Synchronization Service（CSS）：CSS 叢集同步服務，管理叢集配置，誰是成員、誰來、誰走，通知成員，是叢集環境中程式間通訊的基礎。同樣，CSS 也可以用於在單例項環境中處理 ASM 例項與常規 RDBMS 例項之間的互動作用。在叢集環境中，CSS 還提供了組服務，即關於在任意給定時間內哪些節點和例項構成叢集的動態資訊，以及諸如節點的名稱和節點靜態資訊（這些資訊在節點被加入或者移除時被修改）。CSS 維護叢集內的基本鎖功能（儘管大多數鎖有 RDBMS 內部的整合分散式鎖管理來維護）。除了執行其他作業外，CSS 還負責在叢集內節點間維持一個心跳的程式，並監控投票磁碟的 split-brain 故障。在安裝 clusterware 的最後階段，會要求在每個節點執行 root.sh 指令碼，這個指令碼會在/etc/inittab 檔案的最後把這 3 個程式加入啟動項，這樣以後每次系統啟動時，clusterware 也會自動啟動，其中 EVMD 和 CRSD 兩個程式如果出現異常，則系統會自動重啟這兩個程式，如果是 CSSD 程式異常，系統會立即重啟。

注意：

1、Voting Disk 和 OCR 必須儲存在儲存裝置上供各個節點訪問。

2、Voting Disk、OCR 和網路是安裝的過程中或者安裝前必須要指定或者配置的。安裝完成後可以通過一些工具進行配置和修改。

RAC 軟體結構可以分為四部分。

1. 作業系統相關的軟體
2. RAC 共享磁碟部分
3. RAC 中特別的後臺程式和例項程式
4. 全域性緩衝區服務和全域性佇列服務

(一) Operation System-Dependent（OSD）

     RAC 通過作業系統的相關軟體來訪問作業系統和一些與 Cluster 相關的服務程式。OSD 軟體可能由 Oracle 提供（windows 平臺）或由硬體廠商提供（unix 平臺）。OSD 包括三個自部分：

• l  The Cluster Manager(CM)：叢集監視器監視節點間通訊，並通過 interconnect 來協調節點操作。同時還提供 CLUSTER 中所有節點和例項的統一檢視。CM 還控制 CLUSTER 的成員資格。
• l  The Node Monitor（節點監視器）：節點監視器提供節點內各種資源的狀態，包括節點、interconnect 硬體和軟體和共享磁碟等。
• l  The Interconnect 節點間心跳（兩種心跳機制，一種是通過私有網路的 network heartbeat；另一種是通過 voting disk 的 disk heartbeat）

(二) Real Application Cluster Shard Disk Component

       RAC 中這部分元件和單例項 Oracle 資料庫中的元件沒有什麼區別。包括一個或者多個控制檔案、一些列聯機重做日誌檔案、可選的歸檔日誌檔案、資料檔案等。在 RAC 中使用伺服器引數檔案會簡化引數檔案的管理，可以將全域性引數和例項特定的引數儲存在同一個檔案中。

(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：

1. The Global Service Daemon（GSD）：在每個節點上都執行一個全域性服務後臺程式，用於接收客戶端如DBCA、EM 等發出的管理訊息，並完成相應的管理任務，比如例項的啟動和關閉。
2. RAC 中特別的例項程式： Global Cache Service Processes(LMSn)：控制到遠端例項的訊息的流量，管理全域性資料塊的訪問。還用於在不同例項的緩衝區之間傳遞 BLOCK 的對映。
3. Global Enqueue Service Monitor(LMON)：監視全域性佇列和叢集間的資源互動，執行全域性佇列的恢復操作。
4.  Global Enqueue Service Daemon(LMD)：管理全域性佇列和全域性資源訪問。對於每個例項，LMD 管理來自遠端的資源請求。
5. Lock Processes(LCK)：管理除 Cache Fusion 以外的非資料塊資源請求，比如資料檔案，控制檔案，資料字典試圖，library 和 row cache 的請求。
6. Diagnosability Daemon(DIAG)：在例項中捕獲程式失敗的診斷資料。

(四) The Global Cache and Global Enqueue Service

全域性快取服務（GCS）和全域性佇列服務（GES）是 RAC 的整合元件，用於協調對共享資料庫和資料庫內的共享資源的同時訪問。

GCS 和 GES 包括以下特性：

1. 應用透明性。
2. 分散式結構
3. 分散式結構的全域性資源目錄：只要還存在一個節點，即使出現一個或多個節點失敗，GCS 和 GES 仍然可以保證全域性資源目錄的完整性。
4. 資源控制：GCS 和 GES 會選擇一個例項來管理所有的資源資訊，這個例項叫做 resource master。GCS和 GES 會根據資料訪問方式階段性的評估和修改 resource master。這種方式會減少網路流量和資源獲取時間。
5.  GCS 和 GES 與 CM 之間的互動：GCS 和 GES 獨立於 CM。但同時 GCS 和 GES 依賴於 CM 提供的各個節點上例項的狀態資訊。一旦無法取得某個例項的資訊，則 Oracle 會馬上關閉沒有響應的例項，來保證整個 RAC 的完整性。

        健忘問題是由於每個節點都有配置資訊的拷貝，修改節點的配置資訊不同步引起的。Oracle 採用的解決方法就是把這個配置檔案放在共享的儲存上，這個檔案就是 OCR Disk。OCR 中儲存整個叢集的配置資訊，配置資訊以”Key-Value” 的形式儲存其中。在 Oracle 10g 以前，這個檔案叫作 Server Manageability Repository(SRVM). 在 Oracle 10g，這部分內容被重新設計，並重名為 OCR.在 Oracle Clusterware 安裝的過程中，安裝程式會提示使用者指定 OCR 位置。並且使用者指定的這個位置會被記錄在/etc/oracle/ocr.Loc(LinuxSystem) 或者/var/opt/oracle/ocr.Loc(SolarisSystem)檔案中。而在 Oracle 9i RAC 中，對等的是 srvConfig.Loc 檔案。Oracle Clusterware 在啟動時會根據這裡面的內容從指定位置讀入 OCR 內容。

(一) OCR key

整個 OCR 的資訊是樹形結構，有 3 個大分支。分別是 SYSTEM,DATABASE 和 CRS。每個分支下面又有許多小分支。這些記錄的資訊只能由 root 使用者修改。

(二) OCR process

      Oracle Clusterware 在 OCR 中存放叢集配置資訊，故 OCR 的內容非常的重要，所有對 OCR 的操作必須確保OCR 內容完整性，所以在 ORACLE Clusterware 執行過程中，並不是所有結點都能操作 OCR Disk.在每個節點的記憶體中都有一份 OCR 內容的拷貝，這份拷貝叫作 OCR Cache。每個結點都有一個 OCR Process來讀寫 OCR Cache，但只有一個節點的 OCR process 能讀寫 OCR Disk 中的內容，這個節點叫作 OCR Master 結點。這個節點的 OCR process 負責更新本地和其他結點的 OCR Cache 內容。所有需要OCR 內容的其他程式，比如OCSSD,EVM等都叫作Client Process，這些程式不會直接訪問OCR Cache，而是像 OCR Process傳送請求，藉助 OCR Process獲得內容，如果想要修改 OCR 內容，也要由該節點的 OCR Process像 Master node 的 OCR process 提交申請，由 Master OCR Process 完成物理讀寫，並同步所有節點 OCR Cache 中的內容。

      Voting Disk 這個檔案主要用於記錄節點成員狀態，在出現腦裂時，決定那個 Partion 獲得控制權，其他的Partion 必須從叢集中剔除。在安裝 Clusterware 時也會提示指定這個位置。安裝完成後可以通過如下命令來檢視Voting Disk 位置。$Crsctl query css votedisk

一、專用網路

      每個叢集節點通過專用高速網路連線到所有其他節點，這種專用高速網路也稱為叢集互聯或高速互聯 (HSI)。Oracle 的 Cache Fusion 技術使用這種網路將每個主機的實體記憶體 (RAM) 有效地組合成一個快取記憶體。 OracleCache Fusion 通過在專用網路上傳輸某個 Oracle 例項快取記憶體中儲存的資料允許其他任何例項訪問這些資料。它還通過在叢集節點中傳輸鎖定和其他同步資訊保持資料完整性和快取記憶體一致性。專用網路通常是用千兆乙太網構建的，但是對於高容量的環境，很多廠商提供了專門為 Oracle RAC 設計的低延遲、高頻寬的專有解決方案。 Linux 還提供一種將多個物理 NIC 繫結為一個虛擬 NIC 的方法（此處不涉及）來增加頻寬和提高可用性。

二、公共網路

     為維持高可用性，為每個叢集節點分配了一個虛擬 IP 地址 (VIP)。 如果主機發生故障，則可以將故障節點的 IP 地址重新分配給一個可用節點，從而允許應用程式通過相同的 IP 地址繼續訪問資料庫。

三、Virtual lP（VIP）

      即虛擬 IP，Oracle 推薦客戶端連線時通過指定的虛擬 IP 連線，這也是 Oracle10g 新推出的一個特性。其本質目的是為了實現應用的無停頓(雖然目前還是有點小問題，但離目標已經非常接近)。使用者連線虛 IP，這個 IP並非繫結於網路卡，而是由 oracle 程式管理，一旦某個使用者連線的虛 IP 所在例項當機，oracle 會自動將該 IP 對映到狀態正常的例項，這樣就不會影響到使用者對資料庫的訪問，也無須使用者修改應用。Oracle 的 TAF 建立在 VIP 技術之上。IP 和 VIP 區別在與： IP 是利用 TCP 層超時， VIP 利用的是應用層的立即響應。VIP 它是浮動的 IP. 當一個節點出現問題時會自動的轉到另一個節點上。

透明應用故障轉移（Transport Application Failover，TAF）是 oracle 資料提供的一項，普遍應用於 RAC 環境中，當然也可以用於 Data Guard 和傳統的 HA 實現的主從熱備的環境中。TAF 中的 Transparent 和 Failover，點出了這個高可用特性的兩大特點：

1. TAF 是用於故障轉移的，也就是切換。當 Oracle 連線的會話由於資料庫發生故障不可用時，會話能夠自動切換到 RAC 中的其他可用的節點上，或者切換到 Standby 上面，或者切換到 HA 方式中的另一個可用的節點上面。
2. TAF 的故障轉移，對應用來說是透明的，應用系統不需要進行特別的處理就能夠自動進行故障轉移。

但是，TAF 是完美的嗎？是不是使用了 TAF，應用就能真的無縫地進行切換呢？對應用和資料庫有沒有其他什麼要求？要回答這些問題，我們需要全面地瞭解、掌握 TAF。我始終認為，要用好一個東西，首先得掌握這個東西背後的工作原理與機制。首先來看看 Failover。Failover 有兩種，一種是連線時 Failover，另一種則是執行時 Failover。前者的作用在於，應用（客戶端）在連線資料庫時，如果由於網路、例項故障等原因，連線不上時，能夠連線資料庫中的其他例項。後者的作用在於，對於一個已經在工作的會話（也就是連線已經建立），如果這個會話的例項異常中止等，應用（客戶端）能夠連線到資料庫的其他例項（或備用庫）。

      負載均衡（Load-Banlance）是指連線的負載均衡。RAC 的負載均衡主要指的是新會話連線到 RAC 資料庫時，根據伺服器節點的 CPU 負載判定這個新的連線要連線到哪個節點進行工作。Oracle RAC 可以提供動態的資料服務，負載均衡分為兩種，一種是基於客戶端連線的，一種是基於伺服器端的。

       Oracle 的 TAF 建立在 VIP 的技術之上。IP 和 VIP 區別在於：IP 是利用 TCP 層超時，VIP 利用的是應用層的立即響應。VIP 是是浮動的 IP，當一個節點出現問題的時候，會自動的轉到另一個節點上。假設有一個兩節點的 RAC，正常執行時每個節點上都有一個 VIP，即 VIP1 和 VIP2。當節點 2 發生故障，比如異常關係。RAC 會做如下操作：

(一) CRS 在檢測到 rac2 節點異常後，會觸發 Clusterware 重構，最後把 rac2 節點剔除叢集，由節點 1 組成新的叢集。

(二) RAC 的 Failover 機制會把節點 2 的 VIP 轉移到節點 1 上，這時節點 1 的 PUBLIC 網路卡上就有 3 個 IP 地址：VIP1,VIP2, PUBLIC IP1.

(三) 使用者對 VIP2 的連線請求會被 IP 層路由轉到節點 1

(四) 因為在節點 1 上有 VIP2 的地址，所有資料包會順利通過路由層，網路層，傳輸層。

(五) 但是，節點 1 上只監聽 VIP1 和 public IP1 的兩個 IP 地址。並沒有監聽 VIP2，故應用層沒有對應的程式接收這個資料包，這個錯誤立即被捕獲。

(六) 客戶端能夠立即接收到這個錯誤，然後客戶端會重新發起向 VIP1 的連線請求。VIP 特點：

• l  ? VIP 是通過 VIPCA 指令碼建立的。
• l  ? VIP 作為 Nodeapps 型別的 CRS Resource 註冊到 OCR 中，並由 CRS 維護狀態。
• l  ? VIP 會繫結到節點的 public 網路卡上，故 public 網路卡有 2 個地址。
• l  ? 當某個節點發生故障時，CRS 會把故障節點的 VIP 轉移到其他節點上。
• l  ? 每個節點的 Listener 會同時監聽 public 網路卡上的 public ip 和 VIP.
• l  ? 客戶端的 tnsnames.Ora 一般會配置指向節點的 VIP.

Redo Thread

       RAC 環境下有多個例項，每個例項都需要有自己的一套 Redo Log 檔案來記錄日誌。這套 Redo Log 就叫做 RedoThread，其實單例項下也是 Redo Thread，只是這個詞很少被提及，每個例項一套 Redo Thread 的設計就是為了避免資源競爭造成的效能瓶頸。Redo Thread 有兩種，一種是 Private，建立語法 alter database add logfile ......thread n；另一種是 public，建立語法：alter database add logfile......；RAC 中每個例項都要設定 thread 引數，該引數預設值為 0。如果設定了這個引數，則使用預設值 0，啟動例項後選擇使用 Public Redo Thread，並且例項會用獨佔的方式使用該 Redo Thread。RAC 中每個例項都需要一個 Redo Thread，每個 Redo Log Thread 至少需要兩個 Redo Log Group，每個 Log Group成員大小應該相等，沒組最好有 2 個以上成員，這些成員應放在不同的磁碟上，防止單點故障。

注意：在 RAC 環境下，Redo Log Group 是在整個資料庫級別進行編號，如果例項 1 有 1,2 兩個日誌組，那麼例項 2 的日誌組編號就應該從 3 開始，不能使用 1,2 編號了。在 RAC 環境上，所有例項的聯機日誌必須放在共享儲存上，因為如果某個節點異常關閉，剩下的節點要進行 crash recovery，執行 crash recovery 的這個節點必須能夠訪問到故障節點的連線日誌，只有把聯機日誌放在共享儲存上才能滿足這個要求。

Archive log

      RAC 中的每個例項都會產生自己的歸檔日誌，歸檔日誌只有在執行 Media Recovery 時才會用到，所以歸檔日誌不必放在共享儲存上，每個例項可以在本地存放歸檔日誌。但是如果在單個例項上進行備份歸檔日誌或者進行 Media Recovery 操作，又要求在這個節點必須能夠訪問到所有例項的歸檔日誌，在 RAC 幻境下，配置歸檔日誌可以有多種選擇。

1. 使用 NFS

使用 NFS 的方式將日誌直接歸檔到儲存，例如兩個節點，每個節點都有 2 個目錄，Arch1，Arch2 分別對應例項 1 和例項 2 產生的歸檔日誌。每個例項都配置一個歸檔位置，歸檔到本地，然後通過 NFS 把對方的目錄掛到本地。

1. 例項間歸檔（Cross Instance Archive CIA）

例項間歸檔（Cross Instance Archive）是上一種方式的變種，也是比較常見的一種配置方法。兩個節點都建立 2 個目錄 Arch1 和 Arch2 分別對應例項 1 和例項 2 產生的歸檔日誌。每個例項都配置兩個歸檔位置。位置 1對應本地歸檔目錄，位置 2 對應另一個例項

1. 使用 ASM

使用 ASM 將日誌歸檔到共享儲存，只是通過 Oracle 提供的 ASM，把上面的複雜性隱藏了，但是原理都一樣。

Trace 日誌

Oracle Clusterware 的輔助診斷，只能從 log 和 trace 進行。 而且它的日誌體系比較複雜。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log, 這是首選的檢視檔案。

Clusterware 後臺程式日誌

• l  crsd.Log: $ORA_CRS_HOME/log/hostname/crsd/crsd.Log
• l  ocssd.Log: $ORA_CRS_HOME/log/hostname/cssd/ocsd.Log
• l  evmd.Log: $ORA_CRS_HOME/log/hostname/evmd/evmd.Log

Nodeapp 日誌位置

ORACRSHOME/log/hostname/racg/這裡面放的是nodeapp的日誌，包括ONS和VIP，比如：ora.Rac1.ons.Log工具執行日誌：ORACRSHOME/log/hostname/racg/這裡面放的是nodeapp的日誌，包括ONS和VIP，比如：ora.Rac1.ons.Log工具執行日誌：ORA_CRS_HOME/log/hostname/client/

Clusterware 提供了許多命令列工具 比如 ocrcheck, ocrconfig,ocrdump,oifcfg 和 clscfg, 這些工具產生的日誌就放在這個目錄下，還有ORACLEHOME/log/hostname/client/和ORACLEHOME/log/hostname/client/和ORACLE_HOME/log/hostname/racg 也有相關的日誌。

      前面已經介紹了 RAC 的後臺程式，為了更深入的瞭解這些後臺程式的工作原理，先了解一下 RAC 中多節點對共享資料檔案訪問的管理是如何進行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 這個重要的概念，要發揮 Cache Fusion 的作用，要有一個前提條件，那就是網際網路絡的速度要比訪問磁碟的速度要快。否則，沒有引入 Cache Fusion 的意義。而事實上，現在 100MB 的網際網路都很常見。

       Cache Fusion 就是通過網際網路絡（高速的 Private interconnect）在叢集內各節點的 SGA 之間進行塊傳遞，這是RAC最核心的工作機制，他把所有例項的SGA虛擬成一個大的SGA區，每當不同的例項請求相同的資料塊時，這個資料塊就通過 Private interconnect 在例項間進行傳遞。以避免首先將塊推送到磁碟，然後再重新讀入其他例項的快取中這樣一種低效的實現方式(OPS 的實現)。當一個塊被讀入 RAC 環境中某個例項的快取時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他例項知道該塊正在被使用。之後，如果另一個例項請求該塊的一個副本，而該塊已經處於前一個例項的快取內，那麼該塊會通過網際網路絡直接被傳遞到另一個例項的 SGA。如果記憶體中的塊已經被改變，但改變尚未提交，那麼將會傳遞一個 CR 副本。這就意味著只要可能，資料塊無需寫回磁碟即可在各例項的快取之間移動，從而避免了同步多例項的快取所花費的額外 I/O。很明顯，不同的例項快取的資料可以是不同的，也就是在一個例項要訪問特定塊之前，而它又從未訪問過這個塊，那麼它要麼從其他例項 cache fusion 過來，或者從磁碟中讀入。GCS（Global Cache Service，全域性記憶體服務）和 GES（Global EnquenceService，全域性佇列服務）程式管理使用叢集節點之間的資料塊同步互聯。

這裡還是有一些問題需要思考的：

1. 在所有例項都未讀取該塊，而第一個例項讀取時，是怎麼加的鎖，加的什麼鎖？如果此時有另一個例項也要讀這個塊，幾乎是同時的，那麼 Oracle 如何來仲裁，如何讓其中一個讀取，而另一個再從前者的快取中通過 cache 來得到？
2. 如果一個塊已經被其他例項讀入，那麼本例項如何判斷它的存在？
3. 如果某個例項改變了這個資料塊，是否會將改變傳遞到其他例項，或者說其他例項是否會知道並重新更新狀態？
4. 如果一個例項要 swapout 某個塊，而同時其他例項也有這個塊的快取，修改過的和未修改過的，本例項修改的和其他例項修改的，如何操作? truncate 一張表，drop 一張表... 和單例項有何不同？
5. 應該如何設計應用，以使 RAC 真正發揮作用，而不是引入競爭，導致系統被削弱？
6. RAC 下鎖的實現。

      鎖是在各例項的 SGA 中保留的資源，通常被用於控制對資料庫塊的訪問。每個例項通常會保留或控制一定數量與塊範圍相關的鎖。當一個例項請求一個塊時，該塊必須獲得一個鎖，並且鎖必須來自當前控制這些鎖的例項。也就是鎖被分佈在不同的例項上。而要獲得特定的鎖要從不同的例項上去獲得。但是從這個過程來看這些鎖不是固定在某個例項上的，而是根據鎖的請求頻率會被調整到使用最頻繁的例項上，從而提高效率。要實現這些資源的分配和重分配、控制，這是很耗用資源的。這也決定了 RAC 的應用設計要求比較高。假設某個例項崩潰或者某個例項加入，那麼這裡要有一個比較長的再分配資源和處理過程。在都正常執行的情況下會重新分配，以更加有效的使用資源；在例項推出或加入時也會重新分配。在 alert 檔案中可以看到這些資訊。而 Cache Fusion 及其他資源的分配控制，要求有一個快速的網際網路絡，所以要關注與網際網路絡上訊息相關的度量，以測試網際網路絡的通訊量和相應時間。對於前面的一些問題，可以結合另外的概念來學習，它們是全域性快取服務和全域性佇列服務。

      全域性快取服務(GCS):要和 Cache Fusion 結合在一起來理解。全域性快取要涉及到資料塊。全域性快取服務負責維護該全域性緩衝儲存區內的快取一致性，確保一個例項在任何時刻想修改一個資料塊時，都可獲得一個全域性鎖資源，從而避免另一個例項同時修改該塊的可能性。進行修改的例項將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象(post image)。如果另一個例項也請求該塊，那麼全域性快取服務要負責跟蹤擁有該塊的例項、擁有塊的版本是什麼，以及塊處於何種模式。LMS 程式是全域性快取服務的關鍵組成部分。

猜想：Oracle 目前的 cache fusion 是在其他例項訪問時會將塊傳輸過去再構建一個塊在那個例項的 SGA 中，這個主要的原因可能是 interconnect 之間的訪問還是從本地記憶體中訪問更快，從而讓 Oracle 再次訪問時可以從本地記憶體快速獲取。但是這也有麻煩的地方，因為在多個節點中會有資料塊的多個 copy，這樣在管理上的消耗是很可觀的，Oracle 是否會有更好的解決方案出現在後續版本中？如果 interconnect 速度允許的話...）

全域性佇列服務(GES)：主要負責維護字典快取和庫快取內的一致性。字典快取是例項的 SGA 內所儲存的對資料字典資訊的快取，用於高速訪問。由於該字典資訊儲存在記憶體中，因而在某個節點上對字典進行的修改（如DDL)必須立即被傳播至所有節點上的字典快取。GES 負責處理上述情況，並消除例項間出現的差異。處於同樣的原因，為了分析影響這些物件的 SQL 語句，資料庫內物件上的庫快取鎖會被去掉。這些鎖必須在例項間進行維護，而全域性佇列服務必須確保請求訪問相同物件的多個例項間不會出現死鎖。LMON、LCK 和 LMD 程式聯合工作來實現全域性佇列服務的功能。GES 是除了資料塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環境中調節節點間其他資源的重要服務。

SQL> select * from gv$sysstat where name like 'gcs %'

                      

這裡可以看到 gcs 和 ges 訊息的傳送個數。（如果沒有使用 DBCA 來建立資料庫，那麼要 SYSDBA 許可權來執行CATCLUST.SQL 指令碼來建立 RAC 相關的檢視和表）

      Oracle failsafe、Data Guard 和 RAC 均為 ORACLE 公司提供的高可靠性（HA）解決方案。然而之三者之間卻存在著很大區別。HA 是 High Availability 的首字母組合，翻譯過來，可以叫做高可用，或高可用性，高可用（環境）。我覺得應該說 HA 是一個觀念而不是一項或一系列具體技術，就象網格一樣。作過系統方案就知道了，評價系統的效能當中就有一項高可用。也就是 OS 一級的雙機熱備。RAC 是 real application cluster 的簡稱，它是在多個主機上執行一個資料庫的技術，即是一個 db 多個 instance。它的好處是 可以由多個效能較差的機器構建出一個整體效能很好的叢集，並且實現了負載均衡，那麼當一個節點出現故障時，其上的服務會自動轉到另外的節點去執行，使用者甚 至感覺不到什麼。

1、    作業系統：

failsafe 系統侷限於 WINDOWS 平臺，必須配合 MSCS（microsoft cluster server），而 RAC 最早是在 UNIX 平臺推出的，目前已擴充套件至 LINUX 和 WINDOWS 平臺，通過 OSD（operating system dependent）與系統互動。對於高階的 RAC 應用，UNIX 依然是首選的平臺。

2、    系統結構：

FAILSAFE 採用的是 SHARE NOTHING 結構，即採用若干臺伺服器組成叢集，共同連線到一個共享磁碟系統，在同一時刻，只有一臺伺服器能夠訪問共享磁碟，能夠對外提供服務。只要當此伺服器失效時，才有另一臺接管共享磁碟。RAC 則是採用 SHARE EVERYTHING，組成叢集的每一臺伺服器都可以訪問共享磁碟，都能對外提供服務。也就是說 FAILSAFE 只能利用一臺伺服器資源，RAC 可以並行利用多臺伺服器資源。

3、    執行機理：

組成 FAILSAFE 叢集的每臺 SERVER 有獨立的 IP，整個叢集又有一個 IP，另外還為 FAILSAFE GROUP 分配一個單獨的 IP（後兩個 IP 為虛擬 IP，對於客戶來說，只需知道叢集 IP，就可以透明訪問資料庫）。工作期間，只有一臺伺服器（preferred or owner or manager）對外提供服務，其餘伺服器(operator)成待命狀，當前者失效時，另一伺服器就會接管前者，包括FAILSAFE GROUP IP與CLUSTER IP，同時FAILSAFE會啟動上面的DATABASE SERVICE，LISTENER 和其他服務。客戶只要重新連線即可，不需要做任何改動。對於 RAC 組成的叢集，每臺伺服器都分別有自已的 IP，INSTANCE 等，可以單獨對外提供服務，只不過它們都是操作位於共享磁碟上的同一個資料庫。當某臺伺服器失效後，使用者只要修改網路配置，如（TNSNAMES。ORA），即可重新連線到仍在正常執行的伺服器上。但和 TAF 結合使用時，甚至網路也可配置成透明的。

4、    叢集容量：

前者通常為兩臺，後者在一些平臺上能擴充套件至 8 臺。

5、    分割槽：

FAILSAFE 資料庫所在的磁碟必須是 NTFS 格式的，RAC 則相對靈活，通常要求是 RAW，然而若干 OS 已操作出了 CLUSTER 檔案系統可以供 RAC 直接使用。綜上所述，FAILSAFE 比較適合一個可靠性要求很高，應用相對較小，對高效能要求相對不高的系統，而 RAC則更適合可靠性、擴充套件性、效能要求都相對較高的較大型的應用。

RAC 是 OPS 的後繼版本，繼承了 OPS 的概念，但是 RAC 是全新的，CACHE 機制和 OPS 完全不同。RAC 解決了 OPS 中 2 個節點同時寫同一個 BLOCK 引起的衝突問題。 從產品上來說 RAC 和 OPS 是完全不同的產品，但是我們可以認為是相同產品的不同版本

Data Guard 是 Oracle 的遠端複製技術，它有物理和邏輯之分，但是總的來說，它需要在異地有一套獨立的系統，這是兩套硬體配置可以不同的系統，但是這兩套系統的軟體結構保持一致，包括軟體的版本，目錄儲存結構，以及資料的同步（其實也不是實時同步的），這兩套系統之間只要網路是通的就可以了，是一種異地容災的解決方案。而對於 RAC，則是本地的高可用叢集，每個節點用來分擔不用或相同的應用，以解決運算效率低下，單節點故障這樣的問題，它是幾臺硬體相同或不相同的伺服器，加一個 SAN（共享的儲存區域）來構成的。Oracle 高可用性產品比較見下表：

 

通常在 RAC 環境下，在公用網路的基礎上，需要配置兩條專用的網路用於節點間的互聯，在 HACMP/ES 資源的定義中，這兩條專用的網路應該被定義為"private" 。在例項啟動的過程中，RAC 會自動識別和使用這兩條專用的網路，並且如果存在公用"public" 的網路，RAC 會再識別一條公用網路。當 RAC 識別到多條網路時，RAC會使用 TNFF (Transparent Network Failvoer Failback) 功能，在 TNFF 下所有的節點間通訊都通過第一條專用的網路進行，第二條( 或第三條等) 作為在第一條專用的網路失效後的備份。RAC 節點間通訊如下圖所示。

 

      CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一個可選的初始化(init.ora) 引數。此引數可以指定使用哪一條網路用於節點間互聯通訊，如果指定多條網路，RAC 會在這些網路上自動進行負載均衡。然而，當CLUSTER_INTERCONNECTS 設定時，TNFF 不起作用，這將降低 RAC 的可用性，任何一條節點間網際網路絡的失效，都會造成 RAC 一個或多個節點的失效。ORACLE RAC 用於 INTERCONNECT 的內網路卡的物理連線方式的選擇：採用交換機連線或是網線直連。直連的弊端是，一旦一個節點機的內網路卡出現故障，oracle 從 OS 得到兩個節點的網路卡狀態都是不正常的，因而會導致兩個例項都宕掉。在 INTERCONNECT 線路出現問題的時候，oracle 一般情況下會啟動一個競爭機制來決定哪個例項宕掉，如果宕掉的例項正好是好的例項的話， 這樣就會導致兩個例項都宕掉。在 9i 中，oracle 在啟動競爭機制之前，會先等待一段時間，等待 OS 將網路的狀態發給 oracle，如果在超時之前，oracle 獲得哪個例項的網路卡是 down 的話，則將該例項宕掉，這樣的話，則可以保留正常的那個例項繼續服務，否則還是進入競爭機制。

綜上所述節點間通訊分為兩種情況：

? 是接在交換機上面，此時一般情況下，是會保證正常的例項繼續服務的，但有的時候如果 os 來不及將網路卡狀態送到 oracle 時，也是有可能會導致兩個節點都宕掉的。

? 如果是直連的話，則會導致兩個例項都宕掉。

CSS 心跳

OCSSD 這個程式是 Clusterware 最關鍵的程式，如果這個程式出現異常，會導致系統重啟，這個程式提供CSS(Cluster Synchronization Service)服務。 CSS 服務通過多種心跳機制實時監控叢集狀態，提供腦裂保護等基礎叢集服務功能。

CSS 服務有 2 種心跳機制： 一種是通過私有網路的 Network Heartbeat，另一種是通過 Voting Disk 的 DiskHeartbeat。這 2 種心跳都有最大延時，對於 Disk Heartbeat，這個延時叫作 IOT (I/O Timeout);對於 Network Heartbeat, 這個延時叫 MC(Misscount)。這 2 個引數都以秒為單位，預設時 IOT 大於 MC，在預設情況下，這 2 個引數是 Oracle自動判定的，並且不建議調整。可以通過如下命令來檢視引數值：

$crsctl get css disktimeout

$crsctl get css misscount

Oracle RAC 節點間使用的通訊協議見下表。

 

LOCK（鎖）是用來控制併發的資料結構，如果有兩個程式同時修改同一個資料， 為了防止出現混亂和意外，用鎖來控制訪問資料的次序。有鎖的可以先訪問，另外一個程式要等到第一個釋放了鎖，才能擁有鎖，繼續訪問。總體來說,RAC 裡面的鎖分兩種， 一種是本地主機的程式之間的鎖，另外一種是不同主機的程式之間的鎖。本地鎖的機制有兩類，一類叫做 lock（鎖），另外一類叫做 latch 閂。

全域性鎖就是指 RAC lock，就是不同主機之間的鎖，Oracle 採用了 DLM（Distributed Lock Management，分散式鎖管理）機制。在 Oracle RAC 裡面，資料是全域性共享的，就是說每個程式看到的資料塊都是一樣的，在不同機器間，資料塊可以傳遞。給出了 GRD目錄結構。

 

可以看出 Mode、Role、n 構成了 RAC lock 的基本結構

1. Mode 有 N、S、X3 種方式
2. Role 有 Local 和 Global 兩種
3. N 有 PI 和 XI 兩種，一般 0 表示 XI，1 表示 PI
4. 全域性記憶體管理
5. RAC 中的資料庫檔案
6. RAC 中讀的一致性
7. 群集就緒服務（CRS）
8. 全域性資源目錄

資料一致性和併發性描述了 Oracle 如何維護多使用者資料庫環境中的資料一致性問題。在單使用者資料庫中，使用者修改資料庫中的資料，不用擔心其他使用者同時修改相同的資料。但是，在多使用者資料庫中，同時執行的多個事務中的語句可以修改同一資料。同時執行的事務需要產生有意義的和一致性的結果。因而，在多使用者資料庫中，資料併發性和資料一致性的控制非常重要：資料併發性：每個使用者可以看到資料的一致性結果。ANSI/IOS SQL 標準（SQL 92）定義了 4 個事務隔離級別，對事務處理效能的影響也個不相同。這些隔離級別是考慮了事務併發執行必須避免的 3 個現象提出的。3 個應該避免的現象為： ? ?

1. 髒讀：一個事務可以讀取其他事務寫入但還沒有提交的資料。 ? ?
2. 不可重複讀（模糊讀）：一個事務重複讀到以前讀到的和查詢到的資料，這些資料是其他的已提交事務已經修改或者刪除的資料。
3. 幻影讀：一個事務重複執行查詢返回的一些列行，這些行包括其他已經提交的事務已經插入的額外的行。

SQL92 根據這些物件定義了 4 個隔離級別，事務執行在特定的隔離級別允許特別的一些表現。如下表表示隔離級別阻止的讀現象。

 

(一) OCR KEY 是樹形結構。

(二) OCR PROCESS 每個節點都有 OCR CACHE 的複製，由 ORC MASTER 節點負責更新到 OCR DISK

自動啟動的指令碼/etc/inittab 裡定義：

OCSSD（Clustery Synchronization Service）提供心跳機制監控叢集狀態

DISK HEARTBEAT

NETWORK HEARBEAT

CRSD（Clustery Ready Service）提供高可用、干預、關閉、重啟、轉移服務。

資源包括 nodeapps、database-related：前者每個節點只需要一個即可正常工作，後一個與資料庫相關，不受節點限制，可以為多個。

EVMD： 這個程式負責釋出 CRS 產生的各種事件，還是 CRS 和 CSS 兩個服務之間通訊的橋樑

RACGIMON： 這個程式負責檢查資料庫健康狀態，包括資料庫服務的啟動、停止和故障轉移。屬於持久連線，定期檢查 SGA。

OPROCD（Process Monitor Daemon）檢測 CPU hang（非 Linux 平臺使用）

DLM 分散式鎖管理。

1. Non-Cache Fusion 資源：包括資料檔案、控制檔案、資料字典檢視 、Library Cache、Row Cache
2. Cache Fusion 資源：包括普通資料塊、索引資料塊、段頭、UNDO 資料塊。
3. GRD（Global Resource Directory）：記錄每個資料塊在叢集間的分佈圖，在SGA中分master node與shadownode
4. PCM lock：mode role Past Image
5. LMS0（LOCK MANAGER SERVICE）：對應服務為 GCS（Global Cache Service），主要負責資料塊在例項間傳遞Cache fusion 引數 GCS_SERVER_PROCESSES
6. LMD：對應服務為 GES（Global ENQUEUE Service），主要負責傳遞過程中鎖的管理。
7. LCK：負責 NON-CACHE FUSION 資源同步訪問，每個例項有一個程式。
8. LMON：這個程式定期通訊每個例項，對應服務為 CGS（Cluster Group Service）。提供節點監控 node monitor，通過 GRD 中用點陣圖 0,1 來標誌。0：節點關閉 1：節點正常執行通過 CM 層定期通訊。
9. 兩種心跳機制：網路心跳和控制檔案磁碟心跳 3S 一次。
10. DIAG：監控狀態，寫日誌 alert.log
11. GSD：為使用者提供管理介面。

(一) NM（NODE MANAGEMENT）group

(二) 重構叢集觸發：有 node 加入或者離開叢集，由 NM 觸發 Network Heartbeat 異常：因為 LMON 或者 GCS、GES 通訊異常 ，由 IMR（Instance Membership Reconfiguration）controlfile heartbeat 觸發。

(一) 多節點負載均衡

(二) 提供高可用性，故障容錯及無縫切換功能，將硬體和軟體的異常造成的影響最小化。

(三) 通過並行執行技術提供事務響應的時間 - 通常用於資料分析系統。

(四) 通過橫向擴充套件提高每秒交易數和連線數 - 通常用於 OLTP。

(五) 節約硬體成本，可以使用多個廉價的 PC 伺服器代替小型機大型機，節約相應的維護成本。

(六) 可擴充套件性好，可以方便新增刪除節點，擴充套件硬體資源。

(一) 管理更復雜，要求更高

(二) 系統規劃設計較差時效能可能會不如單節點

(三) 可能會增加軟體成本(按照 CPU 收費)

 

在需要將一個 LUN （邏輯單元號）對映給多個節點、為叢集提供一個共享的儲存卷時，同一個儲存 LUN 在各個主機端的 LUNID 必須是相同的。比如：

 (一) 在為多個 ESX 節點建立一個 VMFS 卷的時候

(二) 在雙機 HA 叢集建立共享儲存的時候

叢集模式下，各個節點要協同工作，因此，各主機的時間必須一致。因此，各主機的時間必須一致。各個節點之間的時間差不能超時，一般如果超過 30s，節點很可能會重啟，所以要同步各節點的時間。例如，需要配置一個 ntp 時鐘伺服器，來給 RAC 的各個節點進行時間同步。或者讓節點之間進行時間同步，保證各個節點的時間同步，但是無法保證 RAC 資料庫的時間的準確性。

叢集必須依賴內部的網際網路絡實現資料通訊或者心跳功能。因此，採用普通的乙太網還是其他的高速網路(比如 IB)，就很有講究，當然了，還有拿串列埠線實現心跳資訊傳遞。此外，採用什麼樣的網路引數對叢集整體的效能和健壯性都大有關係。

案例：

XX 市，4 節點 Oracle 10g RAC

作業系統採用的是 RHEL 4，按照預設的安裝文件，設定網路引數為如下值：

net.core.rmem_default = 262144

net.core.rmem_max = 262144

執行一個查詢語句，需要 11 分鐘，修改引數：

net.core.rmem_default = 1048576

net.core.rmem_max = 1048576

再次執行僅需 16.2 秒。

案例：

XX 市，HPC 叢集，執行 LS-DYNA(通用顯示非線性有限元分析程式)。

叢集儲存系統的環境說明：儲存系統的 3 個 I/O 節點通過 FC SAN 交換機連線到一個共享的儲存。

1. 1. 節點使用的 FC HBA 卡為 Qlogic QLE2460;
   2. 光纖交換機為 Brocade 200E
   3. 磁碟陣列為 Dawning DS8313FF

故障現象

叢集到貨後發現盤陣與機器直連能通，兩個裝置接 200E 交換機不通。後經測試交換機 IOS 版本問題導致不能正常認出盤陣的光纖埠，與交換機的供貨商聯絡更新了兩次 IOS，盤陣的埠能正常識別，但盤陣與機器相連還是無法找到盤陣。經過今天的測試發現三臺 I/O 節點採用的 HBA 卡 firmware 版本不一致。最早接光纖交換機及與盤陣直連的的 I/O1 的 firmware 為 v4.03.02，今天又拿出來的兩臺 I/O 節點 firmware 為 v4.06.03。用後兩臺測試後盤陣、機器、交換機之間可以正常通訊，到今天晚上為止沒有發現異常情況。從目前的情況判斷是QLE2460 firmware 為 v4.03.01 的 HBA 卡與 200E IOS V5.3.1 有衝突者不相容導致的故障。至於新的 HBA 卡 firmware為 v4.06.03 與 200E IOS V5.3.1 連線的穩定性如何還要做進一步測試。

診斷處理結果

I/O 1 節點 HBA 卡的 fimware 升級到 v4.06.03 後連線 200E 找不到盤陣的故障已經得到解決。其實是一個 FCHBA 卡的韌體版本不一致引起的問題。

Oracle Cluster Registry（OCR）：記錄 OCR 記錄節點成員的配置資訊，如 database、ASM、instance、 listener、VIP 等 CRS 資源的配置資訊,可儲存於裸裝置或者群集檔案系統上。Voting disk : 即仲裁盤，儲存節點的成員資訊，當配置多個投票盤的時候個數必須為奇數，每個節點必須同時能夠連線半數以上的投票盤才能夠存活。初次之外包含哪些節點成員、節點的新增和刪除資訊。

在 Oracle RAC 中，軟體不建議安裝在共享檔案系統上，包括 CRS_HOME 和 ORACLE_HOME，尤其是 CRS 軟體，推薦安裝在本地檔案系統中，這樣在進行軟體升級，以及安裝 patch 和 patchset 的時候可以使用滾動升級(rolling upgrade)的方式，減少計劃當機時間。另外如果軟體安裝在共享檔案系統也會增加單一故障點。如果使用 ASM 儲存，需要為 asm 單獨安裝 ORACLE 軟體，獨立的 ORACLE_HOME，易於管理和維護，比如當遇到 asm 的 bug 需要安裝補丁時，就不會影響 RDBMS 檔案和軟體。

在一個共享儲存的叢集中，當叢集中 heartbeat 丟失時，如果各節點還是同時對共享儲存去進行操作，那麼在這種情況下所引發的情況是災難的。ORACLE RAC 採用投票演算法來解決這個問題，思想是這樣的：每個節點都有一票，考慮有 A，B，C 三個節點的叢集情形，當 A 節點由於各種原因不能與 B，C 節點通訊時，那麼這叢集分成了兩個 DOMAIN,A 節點成為一個 DOMAIN，擁有一票；B,C 節點成為一個 DOMAIN 擁有兩票，那麼這種情況B，C 節點擁有對叢集的控制權，從而把 A 節點踢出叢集，對要是通 IO FENCING 來實現。如果是兩節點叢集，則引入了仲裁磁碟，當兩個節點不能通訊時，請求最先到達仲裁磁碟的節點擁用對叢集的控制權。網路問題（interconnect 斷了），時間不一致；misscount 超時 等等，才發生 brain split，而此時為保護整個叢集不受有問題的節點影響，而發生 brain split。oracle 採用的是 server fencing，就是重啟有問題的節點，試圖修復問題。當然有很多問題是不能自動修復的。比如時間不一致，而又沒有 ntp；網線壞了。。。這些都需要人工介入修復問題。而此時的表現就是有問題的節點反覆重啟。

從 Oracle10g 起，Oracle 提供了自己的叢集軟體，叫做 Oracle Clusterware，簡稱 CRS，這個軟體是安裝 oraclerac 的前提，而上述第三方叢集則成了安裝的可選項 。同時提供了另外一個新特性叫做 ASM，可以用於 RAC 下的共享磁碟裝置的管理，還實現了資料檔案的條帶化和映象，以提高效能和安全性 (S.A.M.E: stripe and mirroreverything ) ，不再依賴第三方儲存軟體來搭建 RAC 系統。尤其是 Oracle11gR2 版本不再支援裸裝置，Oracle 將全力推廣 ASM，徹底放棄第三方叢集元件支援。

Oracle Clusterware 使用兩種心跳裝置來驗證成員的狀態，保證叢集的完整性。

• l  ? 一是對 voting disk 的心跳，ocssd 程式每秒向 votedisk 寫入一條心跳資訊。
• l  ? 二是節點間的私有乙太網的心跳。

兩種心跳機制都有一個對應的超時時間，分別叫做 misscount 和 disktimeout：

• l  ? misscount 用於定義節點間心跳通訊的超時，單位為秒;
• l  ? disktimeout ,預設 200 秒，定義 css 程式與 vote disk 連線的超時時間;?

reboottime ，發生裂腦並且一個節點被踢出後，這個節點將在reboottime 的時間內重啟;預設是 3 秒。用下面的命令檢視上述引數的實際值：

• l  # crsctl get css misscount
• l  # grep misscount $CRS_HOME/log/hostname/cssd/ocssd.log

在下面兩種情況發生時，css 會踢出節點來保證資料的完整，：

(一) Private Network IO time > misscount，會發生 split brain 即裂腦現象，產生多個“子叢集”(subcluster) ，這些子叢集進行投票來選擇哪個存活，踢出節點的原則按照下面的原則：節點數目不一致的，節點數多的 subcluster 存活;節點數相同的，node ID 小的節點存活。

(二) VoteDisk I/O Time > disktimeout ，踢出節點原則如下：失去半數以上 vote disk 連線的節點將在 reboottime 的時間內重啟。例如有 5 個 vote disk，當由於網路或者儲存原因某個節點與其中>=3 個 vote disk 連線超時時，該節點就會重啟。當一個或者兩個 vote disk 損壞時則不會影響叢集的執行。

對於一個已經有的系統，可以用下面幾種方法來確認資料庫例項的心跳配置，包括網路卡名稱、IP 地址、使用的網路協議。

? 最簡單的方法，可以在資料庫後臺報警日誌中得到。使用 oradebug

SQL> oradebug setmypid

Statement processed.

SQL> oradebug ipc

Information written to trace file.

SQL> oradebug tracefile_name

/oracle/admin/ORCL/udump/orcl2_ora_24208.trc

找到對應 trace 檔案的這一行：socket no 7 IP 10.0.0.55 UDP 16878

? 從資料字典中得到：

SQL> select * from v$cluster_interconnects;

                       

SQL> select * from x$ksxpia;

 

為了避免心跳網路成為系統的單一故障點，簡單地我們可以使用作業系統繫結的網路卡來作為 Oracle 的心跳網路，以 AIX 為例，我們可以使用 etherchannel 技術，假設系統中有 ent0/1/2/3 四塊網路卡，我們繫結 2 和 3 作為心跳：在 HPUX 和 Linux 對應的技術分別叫 APA 和 bonding

UDP 私有網路的調優當使用 UDP 作為資料庫例項間 cache fusion 的通訊協議時，在作業系統上需要調整相關引數，以提高 UDP傳輸效率，並在較大資料時避免出現超出 OS 限制的錯誤：

(一) UDP 資料包傳送緩衝區：大小通常設定要大於(db_block_size * db_multiblock_read_count )+4k，

(二) UDP 資料包接收緩衝區：大小通常設定 10 倍傳送緩衝區;

(三) UDP 緩衝區最大值：設定儘量大(通常大於 2M)並一定要大於前兩個值;

各個平臺對應檢視和修改命令如下：

Solaris 檢視 ndd /dev/udp udp_xmit_hiwat udp_recv_hiwat udp_max_buf ;

修改 ndd -set /dev/udp udp_xmit_hiwat 262144

ndd -set /dev/udp udp_recv_hiwat 262144

ndd -set /dev/udp udp_max_buf 2621440

AIX 檢視 no -a |egrep “udp_|tcp_|sb_max”

修改 no -p -o udp_sendspace=262144

no -p -o udp_recvspace=1310720

no -p -o tcp_sendspace=262144

no -p -o tcp_recvspace=262144

no -p -o sb_max=2621440

Linux 檢視 檔案/etc/sysctl.conf

修改 sysctl -w net.core.rmem_max=2621440

sysctl -w net.core.wmem_max=2621440

sysctl -w net.core.rmem_default=262144

sysctl -w net.core.wmem_default=262144

HP-UX 不需要

HP TRU64 檢視 /sbin/sysconfig -q udp

修改： 編輯檔案/etc/sysconfigtab

inet: udp_recvspace = 65536

udp_sendspace = 65536

Windows 不需要

 

---

---

About Me

............................................................................................................................... ● 本文整理自網路 ● 本文在itpub（http://blog.itpub.net/26736162）、部落格園（http://www.cnblogs.com/lhrbest）和個人微信公眾號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/ ● 本文部落格園地址：http://www.cnblogs.com/lhrbest ● 本文pdf版及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● QQ群：230161599     微信群：私聊 ● 聯絡我請加QQ好友(646634621)，註明新增緣由 ● 於 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ............................................................................................................................... 拿起手機使用微信客戶端掃描下邊的左邊圖片來關注小麥苗的微信公眾號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ群，學習最實用的資料庫技術。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2141231/，如需轉載，請註明出處，否則將追究法律責任。