一． RAC 並發

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才能繼續下一步，即：實例要獲得數據塊的使用權。

Cache Fusion要解決的首要問題就是：數據塊拷貝在集群節點間的狀態分布圖， 這是通過GRD 實現的。

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)

二． RAC 架構

2.1 SGA 的變化

和傳統的單實例相比， RAC Insance的SGA 最顯著的變化就是多了一個GRD部分。 Oracle 中的數據操作都是在內存的SGA區完成的，和傳統的單實例不同，RAC 是有多個，每個數據塊可以在任何一個Instance 的SGA中都有拷貝，RAC必須知道這些拷貝的分布版本，狀態，而GRD就是這些信息的內存區。

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

2.2 後臺進程的變化

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

2.2.1 LMSn

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

2.2.2 LMD

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

2.2.3 LCK

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

2.2.4 LMON

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

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

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

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

2.2.5 DIAG

DIAG 進程監控實例的健康狀態，並在實例出現運行錯誤時手機診斷數據記錄到alert.log 文件

2.2.6 GSD

這個進程負責懂客戶端工具，比如srvctl 接收用戶命令，為用戶提供管理接口。

2.3 文件

Oracle 文件包括二進制執行文件，參數文件（pfile和spfile），密碼文件，控制文件，數據文件，聯機日誌，歸檔日誌，備份文件。

2.3.1 spfile

這個參數文件需要被所有節點訪問，需要放在共享存儲上

2.3.2 Redo Thread

RAC 環境下有多個實例，每個實例都需要有自己的一套Redo log 文件來記錄日誌。這套Redo Log 就叫作一個Redo Thread，其實單實例下也是Redo Thread，只是Thread 這個詞很少被提及，每個實例一套Redo Thread的設計就是為了避免資源競爭造成性能瓶頸。

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的這個節點必須能夠訪問到故障節點的連接日誌，只有把聯機日誌放在共享存儲上才能滿足這個要求。

2.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,把上面的復雜性隱藏了，但原理都一樣。

2.3.4 Undo Tablespace

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

2.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

2.5 Cache Fusion， GCS， GES 關系

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

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

總結：

Oracle RAC 並發與架構