Oracle RAC 併發與架構

一． 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://space.itpub.net/28673746/viewspace-758426

2.5 Cache Fusion， GCS， GES 關係

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

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

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