Oracle RAC 文件參考 [final]

tolywang發表於2010-10-21

http://www.itpub.net/viewthread.php?tid=1099571  

 

Oracle RAC 併發與架構
轉自:http://blog.csdn.net/tianlesoftware/archive/2010/03/07/5353087.aspx

300) { text = text + "\r\n\n本文來自CSDN部落格,轉載請標明出處:" + location.href; clipboardData.setData("text", text); } }, 100); } }

一. 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 負責鎖管理

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

相關文章