Oracle RAC學習筆記01-集群理論

• 1.集群相關理論概述
• 2.Oracle Clusterware
• 3.Oracle RAC 原理

寫在前面：
最近一直在看張曉明的大話Oracle RAC，真實感受就是學到很多之前自己都沒深入思考研究過的知識點，現在趁著節前頭腦尚清醒，再結合實際工作中自己曾遇到的一些案例，就把這段時間自己學到的東西總結一下。

1.集群相關理論概述

一個集群（cluster）由2個或多個節點（nodes）組成。一般集群對外都會有統一的服務接口（集群地址），對內需要（集群內部通信）不斷確定集群內部節點可用，一旦發生異常，可以通過（集群仲裁）驅逐問題Partition，使得集群能夠不影響整體對外提供服務。

集群系統的設計一般都需要考慮2個經典問題：健忘和腦裂。

健忘：集群的配置文件，集群中各節點需要保證集群配置文件的一致性；
Oracle Clusterware集中記錄這些信息到OCR，且整個集群只保留一份配置，各節點共用這份配置，解決了健忘的問題。
腦裂：集群內節點心跳通信故障時，集群需要決定具體哪個partition被踢出集群。
Oracle Clusterware采用兩種心跳機制：網絡心跳和磁盤心跳；當通過私有網絡的網絡心跳故障，需要使用voting disk的磁盤心跳來仲裁Partition剔除。
腦裂問題緊接著還涉及一個IO Fencing問題，即需要保護數據不被故障節點所修改破壞。RAC使用oprocd進程實現IO Fencing。

為了便於學習和理解，將RAC環境分為 存儲層、網絡層、集群層、應用層 4層來分別學習。

存儲層
由SAN組成的存儲層，由於RAC架構是共享存儲，常規場景下只需要有一個存儲。
但如果預算充足，為了進一步提高可用性，我們完全可以在存儲層考慮使用2個存儲，在存儲層構建一個存儲層面的集群。比如使用EMC的vplex，HDS的GAD(Global-Active Device)等。
這種存儲級別的集群，在extended RAC架構中很常見。這一塊基本都偏向於底層存儲層面的知識，與RAC本身關系不大，不再多說。

網絡層
public IP：集群各節點真實IP地址，和其他應用服務器連接在一個交換機上。
10g RAC VIP：在Public IP所在網卡上綁定一個VIP。
優點是：VIP是浮動的，使用VIP，可以避開對TCP協議棧超時的依賴。
11g RAC SCAN IP：在 VIP 基礎上 再引入的scan IP，也有對應的scan IP的監聽。
優點是：使用scan IP配置客戶端連接，以後集群內部添加刪除節點，不需改動客戶端的tns配置。

private IP：集群內部互聯IP，大數據量、低延遲要求，預算低用G級以太網，預算高用infiniband。
網絡心跳（Network Heartbeat）使用這個private IP網絡。
緩存融合（Cache Fusion）也是通過這個private IP網絡進行傳輸。

集群層
集群層是在OS kernel和應用之間的一層。用來統一協調集群內各節點正常調度有序工作。
10g RAC 通過Oracle Clusterware來實現這一層的功能。
11g RAC 改名clusterware為GI。
GI除了名字上的不同，還有很多改變，比如將ASM安裝的集成到GI中，比如GI的安裝一般建議單獨用戶（grid)安裝，而之前clusterware一般都是和數據庫在同一用戶（oracle）安裝的等等，可以簡單認為GI比clusterware更加完善細化了。

應用層
應用層是指在集群件之上的具體應用和資源。
RAC 按照用途主要把應用層分為2大類：nodeapps（節點應用） 和 database-related resource（數據庫資源）。
nodeapps：GSD、ONS、VIP、Listener等。
database-related：Database、Instance、Service等。

2.Oracle Clusterware

Oracle Clusterware是Oracle自己開發的能支持所有平臺的集群件，現在市場上還主要是用於RAC。
它的運行環境由兩個磁盤文件、若幹後臺進程以及網絡元素組成。

2.1 磁盤文件
兩個磁盤文件，即OCR和Voting disk。
在10g RAC中，這兩個文件必須放在真正的裸設備上，不可以放在ASM中。
在11g RAC中，這兩個文件可以放在ASM上。

OCR：
負責維護整個集群的配置信息，包括RAC以及Clusterware資源，包括節點成員、數據庫、實例、服務、監聽器、應用程序等。

Voting disk：
存放在共享存儲上，在集群出現“腦裂”時，仲裁哪個Partition最終獲得集群的控制權。

2.2 後臺進程
大家都知道的Clusterware最重要的進程：
CSS：管理集群內節點
CRS：管理集群資源
EVM：管理事件通知

我們具體來看clusterware中的主要後臺進程：
ocssd: 用來管理集群內節點的加入／踢除。這個進程是clusterware中最關鍵的進程，如果該進程出現異常，會導致系統重啟。
oprocd: 用來實現IO Fencing，早期linux平臺，使用hangcheck-timer模塊來實現IO Fencing，從10.2.0.4開始，Linux平臺也使用oprocd進程。
oclsomon: 用來監控css進程，如果發現進程掛起，會重啟節點。
crsd: 用來管理集群內資源，是實現HA的主要進程。負責管理註冊應用的start、stop、monitor、failover。
racgwrap腳本：CRSD會使用這個腳本來啟動、關閉、檢查實例的狀態。
evmd: 負責發布CRS產生的各種事件。
racgimon: 用來監控集群健康狀態，負責Service的啟動、停止、故障轉移。

2.3 網絡元素
Oracle TAF是建立在VIP技術之上的。
TAF(Transparent Application Failover):對應用透明的故障轉移。

文章前面在網絡層概述提到過：VIP是浮動的，使用VIP，可以避開對TCP協議棧超時的依賴。
原因是：
TCP/IP實際的四層模型從下到上依次為：網絡接口層（MAC）、網絡層（IP）、傳輸層（TCP）、應用層（Listener）。
Public IP 和 VIP都屬於網絡層。
而當節點異常，對應的VIP會飄到其他節點，而其他節點沒有該VIP地址的監聽。VIP利用應用層的立即響應，避開對TCP協議棧超時的依賴。

3.Oracle RAC 原理

拋磚引玉：
GCS、GES、GRD、PCM這些東西是如何堆砌在一起的？
RAC的HA、LB、Cache Fusion...

3.1 數據庫基本原理
數據庫基本原理：同時保證並發和數據一致性。

1) 隔離級別
SQL-92標準中定義了四個隔離級別：Read Uncommitted、Read committed、Repeatable、Serializable。
Oracle 默認實現read committed隔離級別而不影響並發；這也曾是Oracle比較得意的地方。

2) 鎖
數據庫系統使用“鎖”來控制“並發”。

Lock：代表一種控制機制，Lock框架包含3個組件：Resource Structure（資源）、Lock Structure（鎖）、Enqueue（排隊機制）。

Row-Level Lock：對於“數據記錄”這種細粒度資源，Oracle使用的是行級鎖。

行級鎖共涉及以下4種數據結構：
ITL：塊頭ITL，用於記錄哪些事物修改了這個數據塊的內容，可以把它想成一個表格，每行記錄一個事物，包括事物號、事物是否提交等重要信息。
記錄頭ITL索引：每條記錄的記錄頭部有一個字段，用於記錄ITL表項號，可以看作是指向ITL表的指針。
TX鎖：這個鎖代表一個事物，屬於Lock機制。
TM鎖：屬於Lock機制，用於保護對象的定義不被修改。
無論一個事物修改多少個表的多少條記錄，該事物真正需要的只是一個TX鎖，每個表一個TM鎖，內存開銷非常小。而所謂的“行級鎖”只是數據塊頭、數據記錄頭的一些字段，不會消耗額外資源。
因此，對於Oracle的“行級鎖”必須要有正確的理解，它不是Oracle中通常意義上的“鎖”，雖然有鎖的功能，但是沒有鎖的開銷。

Latch: Latch請求，獲得，釋放等操作是原子操作，一般幾個硬件指令就可以完成。是一種低級鎖，主要用於保護數據結構。
也就是說如果請求Latch得不到，不會釋放CPU資源，而會不斷嘗試請求，只有在一定次數還不能獲得時，才釋放CPU。這就是Latch的spin機制。

鎖模式：

--官方文檔中v$lock中LMODE取值
0 - none
1 - null (NULL)
2 - row-S (SS)
3 - row-X (SX)
4 - share (S)
5 - S/Row-X (SSX)
6 - exclusive (X) 

--手工加鎖語句語法參考
lock table &table_name in [ROW] SHARE, [[SHARE] ROW] EXCLUSIVE, SHARE update

--2 - row-S (SS)
lock table t_second_p in row share mode;
lock table t_second_p in share update mode;
--3 - row-X (SX)
lock table t_second_p in row exclusive mode;
--4 - share (S)
lock table t_second_p in share mode;
--5 - S/Row-X (SSX)
lock table t_second_p in share row exclusive mode;
--6 - exclusive (X) 
lock table t_second_p in exclusive mode;

--查看被鎖的對象
select * from v$locked_object;

3) SQL語句執行過程：
用戶發出一條SQL語句，將主要經過解析、優化、產生執行計劃、返回執行結果幾個階段。
如果解析後發現，在shared pool中已經有對應的執行計劃，就可以直接拿來使用，相當於跳過了中間優化、產生執行計劃2個步驟，這就是軟解析。
這個過程中對Lock和Latch的使用：

前三個階段目的就是產生執行計劃，所謂“執行計劃”就是對應shared pool中一個復雜的數據結構。

a. 為了產生這個數據結構，Oracle要計算SQL語句的哈希值，根據這個值確定要檢索的“桶“（Hash Bucket），然後遍歷這個桶中的”鏈表“，看是否有相同的SQL語句。如果沒有，就要進行硬解析。
進程要從shared pool空閑空間中申請一塊空間，用來存放編譯後的執行計劃。這就需要檢索另一個”空閑鏈表“，從中申請一個大小合適的空閑塊，申請成功後要更新這兩個鏈表。在這個過程中，至少
涉及兩個數據鏈表的訪問，這個訪問是”排他“（exclusive）的，不允許其他進程同時修改乃至訪問，這就需要對”鏈表“加鎖，這種鎖用的就是Latch機制。

b. 在語句編譯和執行過程中，“引用對象”的結構不能被更改。在編譯前，需要把表的”元數據“加載到內存，在隨後編譯和執行過程中，這個內容保持不變，也就是不能讓其他用戶改變這個表的結構。
這裏使用的就是TM Lock。

c. 執行階段，要在buffer cache中定位到數據塊，同樣根據數據塊地址查找“桶”中的“鏈表”找到最終的數據塊。在這個過程中，鏈表數據結構也不能被修改，同樣是使用latch保護。訪問數據塊
中的記錄時，也要限制其他進程的訪問，使用的是行級鎖進行保護。

3.2 RAC環境並發控制
1) DLM、Cache Fusion、Non-Cache Fusion
由於要解決多個節點的並發，所以額外引入了DLM（Distribute Lock Management）。
DLM在Oracle發展的不同時期，名字也不相同，在OPS時期，叫做PCM；而在RAC時期叫做Cache Fusion。
在RAC中，DLM是以數據塊作為粒度單位進行協調。

DLM協調集群各節點對資源使用的功能就叫做同步。在DLM中，根據資源數量、活動密集程度將資源分成了兩類：PCM Resource、Non-PCM Resource。[也稱Cache Fusion Resource、Non-Cache Fusion Resource]
對應兩種資源，DLM提供的鎖也是兩種：PCM Lock、Non-PCM Lock。[也稱Cache Fusion Lock、Non-Cache Fusion Lock]
在RAC數據庫中共有兩大類四種鎖：
Local Lock：用於本地進程的並發控制，就是與傳統單實例一樣的，Latch 和 Lock。
Global Lock：用於集群間的並發控制，就是 PCM Lock 和 Non-PCM Lock。

典型的Non-Cache Fusion資源就是row cache和library cache。

PCM Lock 有三種模式，分別對應SGA中數據塊的狀態如下：

PCM Lock Mode    Buffer state
X                        XCUR
S                        SCUR
NULL                     CR

2) GRD
Cache Fusion要解決的首要問題是：數據塊拷貝在集群節點間的狀態分布圖。RAC是通過GRD來實現的。
GRD位於每個實例的SGA中，所有實例的GRD匯總在一起才是一個完整的GRD。
GRD中記錄的是PCM Lock信息，這種鎖有三個屬性：Mode、Role、PI。
Mode：X、S、NULL。
Role：L和G。
PI：Past Image主要能夠加速Crash Recovery的恢復過程。

書中模擬一個場景：4節點RAC，針對一個數據塊，這個數據塊的Master node是節點2。PCM Lock用ModeRolePastimage格式描述，比如SL0代表Share Mode、Local Role、0個Past Image。
分別對並發讀、讀並發寫、寫並發寫、寫入磁盤、寫並發讀等情形，描述了集群相關節點的GRD、PCM Lock的變化過程，體會到Cache Fusion具體是如何工作的。限於篇幅，這裏不再贅述。
總之，無論是單實例還是RAC，實例要修改數據塊，必須獲得這個數據塊的當前版本。

3.3 RAC架構
1) SGA的變化
多了一個GRD（Global Resource Directory）部分，GSD的功能前面已經說過。

2) 後臺進程的變化

LMSn GCS（Global Cache Service），這個進程是Cache Fusion的主要進程，負責數據塊在實例間的傳遞。
LMD GES（Global Enqueue Service），這個進程負責在多個實例之間協調對數據塊的訪問順序。它與LMSn進程的GCS服務還有GRD共同構成RAC最核心的功能Cache Fusion。
LCK 這個進程負責Non-Cache Fusion資源的同步訪問。
LMON 各個實例等LMON進程會定期通信，檢查集群中各節點的健康狀態。負責集群重構、GRD恢復等操作，它提供的服務叫做CGS（Cluster Group Services）。
LMON提供節點監控功能：通過一個保存在GRD中的位圖來記錄（0代表節點關閉，1代表節點正常）；
LMON檢測到實例級別的“腦裂”時，會通知clusterware解決，如果等待超時，LMON進程會自動觸發IMR（Instance Membership Recovery）。
LMON進程提供的IMR功能可以看作是Oracle在數據庫層提供的“腦裂”，“IO隔離”機制。（LMON也借助兩種心跳：網絡心跳、控制文件的磁盤心跳）。
DIAG DIAG監控實例的健康狀態，並在實例運行錯誤時收集診斷數據到Alert.log日誌中。
GSD GSD進程負責從客戶端工具，比如srvctl接收用戶命令，為用戶提供管理接口。

3) 文件
spfile 需要被所有節點訪問，存放在共享存儲上。
redo thread 每個實例都需要自己的一套redo log。需要被所有節點訪問，存放在共享存儲上。
archived log 建議存放在共享存儲上。當然也有其他設計方式。
undo tablespace 每個實例都需要有一個單獨的回滾表空間。存放在共享存儲上。

4) SCN
在RAC中，由GCS負責全局維護SCN的產生，ORACLE 10g RAC 缺省使用的是Broadcast算法，可以從alert.log中看到。

5) Cache Fusion、GCS、 GES
GCS負責數據塊在實例間的傳遞；
GES負責鎖管理。

3.4 RAC和Clusterware的交互
RAC集群和節點集群是兩個層次的集群，兩個集群都有腦裂、IO隔離等問題。
兩個集群有各自的故障檢測機制，二者之間的機制可以有重疊也可以不同。
在RAC這一層出現節點故障時，首先會通知clusterware這種異常，等待clusterware完成集群重構，完成後再通知RAC，RAC集群再開始自己的重構，但是RAC並不完全依賴於clusterware解決問題，如果發生等待超時，RAC的LMON進程會自動觸發IMR執行節點排除。

Reference

• 張曉明. 大話Oracle RAC[M]. 人民郵電出版社, 2011.
• 張曉明. 大話Oracle Grid[M]. 人民郵電出版社, 2014.
  

文章來源：