Oracle RAC 深度解析之(1)

Oracle RAC 深度解析之(2)
（以下在原文基礎上做了，微改了部分內容）

一、 工作機制

1.1 併發控制
在叢集環境中， 關鍵資料通常是共享存放的，比如放在共享磁碟上。 而各個節點的對資料有相同的訪問許可權， 這時就必須有某種機制能夠控制節點對資料的訪問。 Oracle RAC 是利用DLM(Distribute Lock Management) 機制來進行多個例項間的併發控制。

1.2 健忘症(Amnesia)
叢集環境配置檔案不是集中存放的，而是每個節點都有一個本地副本，在叢集正常執行時，使用者可以在任何節點更改叢集的配置，並且這種更改會自動同步到其他節點。
有一種特殊情況： 節點A 正常關閉， 在節點B上修改配置， 關閉結點B，啟動結點A。這種情況下，修改的配置檔案是丟失的， 就是所謂的健忘症。

1.3 腦裂(Split Brain)
在叢集中，節點間通過某種機制(心跳)瞭解彼此的健康狀態，以確保各節點協調工作。 假設只有"心跳"出現問題， 各個節點還在正常執行， 這時，每個節點都認為其他的節點宕機了， 自己是整個叢集環境中的"唯一建在者"，自己應該獲得整個叢集的"控制權"。 在叢集環境中，儲存裝置都是共享的， 這就意味著資料災難，這種情況就是"腦裂"解決這個問題的通常辦法是使用投票演算法(Quorum Algorithm). 它的演算法機理如下：

叢集中各個節點需要心跳機制來通報彼此的"健康狀態"，假設每收到一個節點的"通報"代表一票。對於三個節點的叢集，正常執行時，每個節點都會有3票。當節點A心跳出現故障但節點A還在執行，這時整個叢集就會分裂成2個小的partition。 節點A是一個，剩下的2個是一個。 這是必須剔除一個partition才能保障叢集的健康執行。
對於有3個節點的叢集， A 心跳出現問題後， B 和 C 是一個partion，有2票， A只有1票。 按照投票演算法， B 和C 組成的叢集獲得控制權， A 被剔除。

如果只有2個節點，投票演算法就失效了。 因為每個節點上都只有1票。 這時就需要引入第三個裝置：Quorum Device. Quorum Device 通常採用的是共享磁碟，這個磁碟也叫作Quorum disk。 這個Quorum Disk 也代表一票。 當2個節點的心跳出現問題時， 2個節點同時去爭取Quorum Disk 這一票， 最早到達的請求被最先滿足。故最先獲得Quorum Disk的節點就獲得2票。另一個節點就會被剔除。

1.4 IO 隔離(Fencing)
當集群系統出現"腦裂"問題的時候，我們可以通過"投票演算法"來解決誰獲得叢集控制權的問題。 但是這樣是不夠的，我們還必須保證被趕出去的節點不能操作共享資料。這就是IO Fencing 要解決的問題。
IO Fencing實現有硬體和軟體2種方式：

軟體方式：對於支援SCSI Reserve/Release 命令的儲存裝置，可以用SG命令來實現。 正常的節點使用SCSI Reserve命令"鎖住"儲存裝置， 故障節點發現儲存裝置被鎖住後，就知道自己被趕出了叢集，也就是說自己出現了異常情況，就要自己進行重啟，以恢復到正常狀態。 這個機制也叫作 suicide(自殺). Sun 和Veritas 使用的就是這種機制。

硬體方式：STONITH(Shoot The Other Node in the Head)， 這種方式直接操作電源開關，當一個節點發生故障時，另一個節點如果能偵測到，就會通過串列埠發出命令，控制故障節點的電源開關，通過暫時斷電，而又上電的方式使故障節點被重啟動，這種方式需要硬體支援。

二、 叢集

2.1 Clusterware

在單機環境下，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 組成的叢集。

2.2 Clusterware 組成

Oracle Cluster 是一個單獨的安裝包，安裝後，在每個結點上的Oracle Clusterware 會自動啟動。 Oracle Clusterware的執行環境由：2個磁碟檔案(OCR,Voting Disk)、若干程序、網路元素(VIP)組成。

2.2.1 磁碟檔案

Clusterware 在執行期間需要兩個檔案：OCR和Voting Disk. 這2個檔案必須存放在共享儲存上。 OCR 用於解決健忘問題，Voting Disk 用於解決腦裂問題。 Oracle 建議使用裸裝置來存放這2個檔案，每個檔案建立一個裸裝置，每個裸裝置分配100M左右的空間就夠了。

2.2.1.1 OCR

健忘問題是由於每個節點都有配置資訊的拷貝，修改節點的配置資訊不同步引起的。 Oracle 採用的解決方法就是把這個配置檔案放在共享的儲存上， 這個檔案就是OCR Disk。

OCR 中儲存整個叢集的配置資訊，配置資訊以"Key-Value" 的形式儲存其中。 在Oracle 10g以前，這個檔案叫作Server Manageability Repository(SRVM).在Oracle 10g， 這部分內容被重新設計，並重名為OCR.在Oracle Clusterware 安裝的過程中， 安裝程式會提示使用者指定OCR位置。並且使用者指定的這個位置會被記錄在/etc/oracle/ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)檔案中。 而在Oracle 9i RAC中，對等的是srvConfig.Loc檔案。 Oracle Clusterware在啟動時會根據這裡面的內容從指定位置讀入OCR 內容。

1). OCR key
整個OCR 的資訊是樹形結構，有3個大分支。分別是SYSTEM、DATABASE、CRS。每個分支下面又有許多小分支。這些記錄的資訊只能由root使用者修改。
2). 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中的內容。

2.2.1.2 Voting Disk

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

2.2.2 Clusterware 後臺程序
Clusterware 由若干程序組成，其中最重要的3個是：CRSD、CSSD、EVMD. 在安裝clusterware的最後階段，會要求在每個節點執行root.sh 指令碼， 這個指令碼會在/etc/inittab 檔案的最後把這3個程序加入啟動項，這樣以後每次系統啟動時，Clusterware 也會自動啟動，其中EVMD和CRSD 兩個程序如果出現異常，則系統會自動重啟這兩個程序，如果是CSSD 程序異常，系統會立即重啟。
1). OCSSD

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

CSS 服務有2種心跳機制： 一種是通過私有網路的Network Heartbeat，另一種是通過Voting Disk的Disk Heartbeat.

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

$crsctl get css disktimeout
$crsctl get css miscount

[[email protected] ~]# crsctl get css disktimeout
200
[[email protected] ~]# crsctl get css misscount
30

注：除了Clusterware 需要這個程序，在單節點環境中如果使用了ASM，也需要這個程序；這個程序用於支援ASM Instance 和RDBMS Instance之間的通訊。 如果在使用了ASM的節點上安裝RAC，會遇到一個問題：RAC節點要求只有一個OCSSD程序，並且應該是執行$CRS_HOME目錄下的，這時就需要先停止ASM，並通過

$ORACLE_HOME/bin/localcfig.Sh delete 

刪除之前的inittab 條目。 之前安裝ASM時，也使用這個指令碼來啟動OCSSD：

  $ORACLE_HOME/bin/localconfig.Sh add

2). CRSD

CRSD是實現"高可用性(HA)"的主要程序，它提供的服務叫作CRS(Cluster Ready Service) 服務。

Oracle Clusterware是位於叢集層的元件，它要為應用層資源(CRS Resource) 提供"高可用性服務"，所以， Oracle Clusterware 必須監控這些資源，並在這些資源執行異常時進行干預，包括關閉，重啟程序或者轉移服務。CRSD程序提供的就是這些服務。

所有需要 高可用性 的元件，都會在安裝配置的時候，以CRS Resource的形式登記到OCR中，而CRSD 程序就是根據OCR中的內容，決定監控哪些程序，如何監控，出現問題時又如何解決。也就是說，CRSD 程序負責監控CRS Resource 的執行狀態，並要啟動，停止，監控，Failover這些資源。預設情況下，CRS 會自動嘗試重啟資源5次，如果還是失敗，則放棄嘗試。

CRS Resource 包括GSD(Global Service Daemon)、ONS(Oracle Notification Service)、VIP、 Database、 Instance 和 Service. 這些資源被分成2類：

GSD、ONS、VIP 和 Listener 屬於Nodeapps類

Database，Instance 和Service 屬於 Database-Related Resource 類。

我們可以這樣理解： Nodeapps 就是說每個節點只需要一個就夠了，比如每個節點只有一個Listener，而Database-Related Resource 就是說這些資源和資料庫有關，不受節點的限制，比如一個節點可以有多個例項，每個例項可以有多個Service。

GSD、ONS、VIP 這3個服務是在安裝Clusterware的最後，執行VIPCA 時建立並登記到OCR中的。 而Database、 Listener、 Instance 和Service 是在各自的配置過程中自動或者手動登記到OCR中的。

3). EVMD

EVMD 這個程序負責釋出CRS 產生的各種事件(Event). 這些Event可以通過2種方式釋出給客戶：ONS 和 Callout Script. 使用者可以自定義回撥指令碼，放在特定的目錄下，這樣當有某些事件發生時，EVMD會自動掃描該目錄，並呼叫使用者的指令碼，這種呼叫是通過racgevt程序來完成的。

EVMD 程序除了複雜釋出事件之外，它還是CRSD 和CSSD 兩個程序之間的橋樑。 CRS 和CSS 兩個服務之前的通訊就是通過EVMD 程序完成的。

4). RACGIMON

RACGIMON 這個程序負責檢查資料庫健康狀態，負責Service的啟動，停止，故障轉移(Failover)。 這個程序會建立到資料庫的持久連線，定期檢查SGA中的特定資訊，該資訊由PMON 程序定時更新。

5). OPROCD

OPROCD 這個程序也叫作 Process Monitor Daemon.如果在非Linux 平臺上，並且沒有使用第三方的叢集軟體時，就會看到這個程序。 這個程序用來檢查節點的Processor Hang(CPU 掛起), 如果排程時間超過1.5秒， 就會認為CPU 工作異常，會重啟節點。 也就是說這個程序提供 “IO 隔離” 的功能。 從其在Windows 平臺上的服務名： OraFnceService 也可以看出它的功能。而在Linux 平臺上， 是利用Hangcheck-timer 模組來實現"IO 隔離"的。

2.3 VIP 原理和特點

Oracle 的TAF (Transparent Application Failover)就是建立在VIP 技術之上的。 IP 和VIP 區別在與： IP 是利用TCP層超時， VIP 利用的是應用層的立即響應。VIP 它是浮動的IP. 當一個節點出現問題時會自動的轉到另一個節點上。

假設有一個2個節點的RAC，正常執行時每個節點上都有一個VIP。 VIP1 和VIP2. 當節點2發生故障，比如異常關係。RAC 會做如下操作：

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

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

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

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

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

6). 客戶段能夠立即接收到這個錯誤，然後客戶段會重新發起向VIP1的連線請求。

VIP 特點：

1). VIP 是通過VIPCA指令碼建立的

2). VIP 作為Nodeapps型別的CRS Resource 註冊到OCR中，並由CRS 維護狀態。

3). VIP 會繫結到節點的public 網絡卡上，故public 網絡卡有2個地址。

4). 當某個節點發生故障時，CRS 會把故障節點的VIP 轉移到其他節點上。

5). 每個節點的Listener 會同時監聽public 網絡卡上的 public ip 和VIP

6). 客戶端的tnsnames.Ora 一般會配置指向節點的VIP.

2.4 Clusterware 的日誌體系

Oracle Clusterware的輔助診斷，只能從log 和trace 進行。 而且它的日誌體系比較複雜。

alert.log:

$ORA_CRS_HOME\log\hostname\alert.Log, 這是首選的檢視檔案。

Clusterware後臺程序日誌：

crsd.Log: $ORA_CRS_HOME\log\hostname\crsd\crsd.Log

ocssd.Log: $ORA_CRS_HOME\log\hostname\cssd\ocsd.Log

evmd.Log: $ORA_CRS_HOME\log\hostname\evmd\evmd.Log

Nodeapp日誌位置：

$ORA_CRS_HOME\log\hostname\racg\

這裡面放的是nodeapp的日誌，包括ONS和VIP，比如：ora.Rac1.ons.Log

工具執行日誌：

$ORA_CRS_HOME\log\hostname\client\

Clusterware 提供了許多命令列工具：

比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 這些工具產生的日誌就放在這個目錄下

還有$ORACLE_HOME\log\hostname\client\ 和

$ORACLE_HOME\log\hostname\racg 也有相關的日誌。

三． 併發機制

RAC 的本質是一個數據庫，執行在多臺計算機上的資料庫，它的主要任務是資料庫就是事務處理，它通過 Distributed Lock Management(DLM:分散式鎖管理器) 來解決併發問題。因為RAC的資源是共享的，為了保證資料的一致性，就需要使用DLM來協調例項間對資源的競爭訪問。RAC 的DLM 就叫作 Cache Fusion。

在DLM 中，根據資源數量，活動密集程度，把資源分成兩類：Cache Fusion和Non-Cache Fusion。

Cache Fusion Resource指資料塊這種資源，包括普通資料庫，索引資料庫，段頭塊(Segment Header),undo 資料庫。

Non-Cache Fusion Resource是所有的非資料庫塊資源, 包括資料檔案，控制檔案，資料字典，Library Cache，share Pool的Row Cache等。Row Cache 中存放的是資料字典，它的目的是在編譯過程中減少對磁碟的訪問。

在Cache Fusion中，每一個數據塊都被對映成一個Cache Fusion資源，Cache Fusion 資源實際就是一個數據結構，資源的名稱就是資料塊地址（DBA）。每個資料請求動作都是分步完成的。首先把資料塊地址X轉換成Cache Fusion 資源名稱，然後把這個Cache Fusion 資源請求提交給DLM， DLM 進行Global Lock的申請，釋放活動，只有程序獲得了PCM Lock( Parallel Cache Management)才能繼續下一步，即：例項要獲得資料塊的使用權。

PCM - Parallel Cache Management
Oracle使用 PCM（ Parallel Cache Management） 維護緩衝區的一致性，通過PCM Oracle允許一個節點訪問位於另一個節點的緩衝區Cache中的資料；
IDLM - Integrated Distributed Lock Manager
Oracle通過整合分散式鎖管理器（Integrated Distributed Lock Manager，IDLM）來協調資源的使用，防止發生衝突,從而實現PCM 並行Cache管理,專門的LCK程序用於實現例項間的資料一致。

Oracle並行伺服器中的每個PCM鎖可管理多個數據塊。PCM鎖管理的資料塊的個數與分配給一個數據檔案的PCM鎖的個數及該資料檔案的大小有關。一旦某個節點上的例項啟動後，它就可以獲取各種各樣的DLM鎖，這些鎖主要劃分為 PCM（Parallel Cache Management，並行Cache管理）鎖和非PCM鎖。PCM鎖用於鎖住資料庫塊，非PCM鎖用於鎖住所有其他的共享DLM資源（例如共享池中的資料檔案和物件）
Cache Fusion要解決的首要問題就是：資料塊拷貝在叢集節點間的狀態分佈圖，這是通過GRD 實現的。

3.1 GRD（Global Resource Directory）

可以把GRD 看作一個內部資料庫，這裡記錄的是每一個數據塊在叢集間的分佈圖，它位於每一個例項的SGA中，但是每個例項SGA中都是部分GRD，所有例項的GRD彙總在一起就是一個完整的GRD。

RAC 會根據每個資源的名稱從叢集中選擇一個節點作為它的Master Node，而其他節點叫作Shadow Node. Master Node 的GRD中記錄了該資源在所有節點上的使用資訊，而Shadow Node的GRD中只需要記錄資源在該節點上的使用情況，這些資訊實際就是PCM Lock資訊。PCM Lock 有3個屬性： Mode，Role 和 PI(Past Image).

3.2 快取融合原理

群集環境中所有節點共享且併發地對磁碟上的資料庫進行更新，另外還要額外地需要同其它節點進行同步和序列機制，以避免兩個或多個節點同時更新同一資料頁上的記錄。舉個例子說明一下：

（1） 節點A讀取一個全新的資料塊，該資料塊沒有被任何節點讀入
①節點A的請求發給GCS，GCS把這個請求轉發給這個資料塊的主節點，這裡假定是節點B。因為這個資料塊沒有在任何節點的記憶體中，GCS標記這個資料塊狀態為S（shared，共享狀態），並記錄到GRD中。
②接著B告訴節點A狀態修改了，準備工作都完成了。然後節點A記錄共享狀態在自己的例項中，並讀入該資料塊。這時，節點A持有了該資料塊，並在GRD中進行記錄，標記持有該資料塊。此時，整個過程發生了一次IO操作。

（2） 節點C要修改剛才節點A讀入的資料塊，這裡假定節點A剛才讀入的資料塊SCN是100。
①節點C找到該資料塊的主節點，也就是節點B，要求能加一個X標記（exclusive，獨佔狀態），表明要修改資料。但是這個資料塊可能已經存在於多個節點的例項中，每個例項都有個S標記。
②GCS會告訴所有持有該資料塊的例項，把狀態S標記轉換為N標記（null，空狀態）。
③最後一個從S標記轉換為N標記的例項把資料塊傳送到需要對其進行修改的節點如節點C上。
④這時節點C的例項就可以對該資料塊加上X標記，並通知該資料塊的主節點，也就是節點B的GCS，GCS將最新的標記與位置記錄到GRD，並關閉以前節點的資源記錄。這時節點C就可以修改該資料塊了，假定把SCN從100修改成了101，這個時候磁碟上的資料塊SCN還是100，整個過程是通過內部互聯進行資料交換，沒有磁碟IO產生。

（3） 節點D也要修改該資料塊
①與節點C修改該資料塊類似，節點D也會找到該資料塊的主節點，也就是節點B，要求加一個X（exclusive，獨佔狀態）的鎖，表示要修改該資料塊。
②這時GCS會告訴上一次修改成功的節點C，放棄它加上的X標記，因為別的節點也要修改這個資料塊。
③節點C會確保這個資料塊的改變，已經記入聯機日誌中，然後轉換X標記為N標記，並把這個資料塊拷貝到節點D。
④節點D加上X標記，並通知該資料塊的主節點，也就是節點B的GCS，GCS將最新的標記與位置揭露到GRD，並關閉以前節點上的資源記錄。這時節點D就可以修改該資料塊了，假定把該資料塊的SCN從101又修改成102，但是磁碟的資料塊上的SCN還是100。可以發現RAC在這個過程中，也沒有任何磁碟操作，同樣是通過內部互聯來完成的。

（4） 節點A要重新讀取該資料塊
①節點A還是一樣，首先找到該資料塊的主節點，也就是節點B，希望能讀取最新的資料塊，也就是SCN為102的內容。
②GCS根據GRD得知最新的資料塊在節點D上，於是GCS通知節點D。節點D需要確保剛才修改過的資料塊已經記錄在聯機日誌中，如果已經確定記錄過，則把原來的X標記轉換為S標記。
③節點D拷貝資料塊到節點A的例項，這時節點A獲得該資料塊，並獲得S標記。
④最後再告訴該資料塊的主節點，也就是節點B，GCS記錄最新的標記與位置到GRD，這個時候，節點A與節點D同時持有S標記的相同的資料塊，資料塊的SCN為102，但是磁碟中的資料塊SCN還是100，最後如果發生寫操作，只要最新的一個節點發生寫操作即可，所以該資料塊雖然在不同節點、不同例項中發生了多次改變，最終卻只有一次寫IO操作。

四． RAC 架構

4.1 SGA 的變化

和傳統的單例項相比， RAC Insance的SGA 最顯著的變化就是多了一個GRD部分。 Oracle 中的資料操作都是在記憶體的SGA區完成的，和傳統的單例項不同，RAC 是有多個，每個資料塊可以在任何一個Instance 的SGA中都有拷貝，RAC必須知道這些拷貝的分佈版本，狀態，而GRD就是這些資訊的記憶體區。

GRD 雖然位於SGA中，但是不像Buffer Cache 或者 Log buffer等SGA 元件，有明確的引數來對應，每個節點中都只有部分GRD內容，所有的節點合在一起才構成完整的GRD.

4.2 後臺程序的變化

每個RAC的例項和傳統的單例項一樣，都有DBWR、LGWR、ARCn、CKPT 這些後臺程序，除了這些程序外，每個例項還增加了若干RAC特有的程序，要注意的是，這些程序名稱和程序提供的服務名稱差異很大，比如LMS程序提供的是GCS 服務，很不便與記憶，造成這種現象的原因是程序名稱從9i 之前的OPS（RAC 前身）延續下來的，但是服務卻已經在RAC中重新設計並命名。

4.2.1 LMSn (全域性快取服務程序 Global Cache Service Process)

這個程序是Cache Fusion的主要程序，負責資料塊在例項間的傳遞，對應的服務叫作GCS(Global Cache Service), 這個程序的名稱來源與Lock Manager Service。 從Oracle 9開始，Oracle 對這個服務重新命名成Global Cache Service, 但是程序名字確沒有調整。這個程序的數量是通過引數GCS_SERVER_PROCESSES 來控制，預設值是2個，取值範圍為0-9.

4.2.2 LMD(全域性佇列服務守護程序 Global Enqueue Service Daemon)

這個程序負責的是Global Enqueue Service（GES），具體來說，這個程序負責在多個例項之間協調對資料塊的訪問順序，保證資料的一致性訪問。 它和LMSn程序的GCS服務還有GRD共同構成RAC最核心的功能Cache Fusion。

4.2.3 LCK0 (例項佇列程序)

這個程序負責Non-Cache Fusion 資源的同步訪問，每個例項有一個LCK 程序

4.2.4 LMON(全域性佇列服務監控器 Global Enqueue Service Monitor)

各個例項的LMON程序會定期通訊，以檢查叢集中各個節點的健康狀態，當某個節點出現故障時，負責叢集重構，GRD恢復等操作，它提供的服務叫作：Cluster Group Services（CGS）。

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

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

2） 通過控制檔案的磁碟心跳（Controlfile Heartbeat）： 每個節點的CKPT程序每隔3秒更新一次控制檔案一個數據塊，這個資料塊叫作Checkpoint Progress Record，控制檔案是共享的，所以例項間可以相互檢查對方是否及時更新來判斷。

4.2.5 DIAG (診斷守護程序)

DIAG 程序監控例項的健康狀態，並在例項出現執行錯誤時手機診斷資料記錄到alert.log 檔案

4.2.6 GSD(Global Service Daemon)

這個程序負責客戶端工具，用於支援dbca,srvctl,oem等的互動工具，為使用者提供管理介面。Oracle 11g RAC預設將oc4j以及gsd服務都處於offline狀態。

4.3 檔案

Oracle 檔案包括二進位制執行檔案，引數檔案（pfile和spfile），密碼檔案，控制檔案，資料檔案，聯機日誌，歸檔日誌，備份檔案。

4.3.1 spfile

這個引數檔案需要被所有節點訪問，需要放在共享儲存上

4.3.2 Redo Thread

每個例項用到的聯機日誌就是一個Redo Thread，單例項有且只有一個Redo Thread。在RAC環境下，每個例項都需要自己的聯機日誌，也就是每個例項都有自己的Redo Thread。這種每例項一個Redo Thread的設計是為了避免例項間共享Redo檔案引發的競爭，提高系統性能。

Redo Thread有兩種，一種是Private 的，建立語法： alter database add logfile … Thread n; 另一種是public，建立語法：alter database add logfile…; RAC 中每個例項都要設定thread 引數，該引數預設值為0. 如果設定了這個引數，則例項啟動時，會使用等於該Thread的Private Redo Thread。如果沒有設定這個引數，則使用預設值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，3三個日誌組，那麼例項2的日誌組就應該從4開始編號，不能在使用1，2，3這三個編號。

在RAC 環境下，所有例項的聯機日誌必須放在共享儲存上，因為如果某個節點異常關閉，剩下的節點要進行Crash Recovery， 執行Crash Recovery的這個節點必須能夠訪問到故障節點的聯機日誌，只有把聯機日誌放在共享儲存上才能滿足這個要求。

RAC環境下如有多個private日誌執行緒，則在新增日誌時必須指定執行緒號。

SQL> alter database add logfile thread 1
group 5 ('/oracle/oradata/redo5') size 50M; 

4.3.3 Archived Log

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

1）使用NFS

這種方式實際是歸檔到共享儲存，比如2個節點，每個節點都有2個目錄，Arch1，Arch2分別對應例項1和例項2的日誌。每個例項只配置一個歸檔位置，歸檔到本地，然後通過NFS 把對方的目錄掛到本地。

2）例項間歸檔（CIA: Cross Instance Archive）

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

3）使用ASM

這種方式也是歸檔到共享儲存，只是通過Oracle 提供的ASM,把上面的複雜性隱藏了，但原理都一樣。

4.3.4 Undo Tablespace

和Redo Log 一樣，在RAC 環境下，每個例項都需要有一個單獨的回滾表空間，這個是通過引數SID.undo_tablespace 來配置的。

4.4 SCN(System Change Number)

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

RedoLog Checkpoint 和 SCN關係

http://blog.csdn.net/tianlesoftware/archive/2010/01/25/5251916.aspx

4.5 Cache Fusion、 GCS、GES 關係

Cache Fusion（記憶體融合）是通過高速的Private Interconnect，在例項間進行資料塊傳遞，它是RAC 最核心的工作機制，它把所有例項的SGA虛擬成一個大的SGA區。每當不同的例項請求相同的資料塊時，這個資料塊就通過Private Interconnect 在例項間進行傳遞。

整個Cache Fusion 有兩個服務組成：GCS 和GES。 GCS 負責資料庫在例項間的傳遞，GES 負責鎖管理