Oracle RAC 並發與架構

標籤：日誌組   方式   mit   current   ble   並發   一個資料庫   buffer   str   

10g 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://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 負責鎖管理

 

 

 

總結：

 lms和lmd共同負責gcs

gcs和ges共同組成grd

而這一套服務就是dlm 

 

Oracle RAC 並發與架構