緩存融合技術和主要后台進程（四）
概述：寫下本文檔的初衷和動力，來源於上篇的《oracle基本操作手冊》。oracle基本操作手冊是作者研一假期對oracle基礎知識學習的匯總。然后形成體系的總結，一則進行回顧復習，另則便於查詢使用。本圖文文檔亦源於此。閱讀Oracle RAC安裝與使用教程前，筆者先對這篇文章整體構思和形成進行梳理。由於閱讀者知識儲備層次不同，我將從Oracle RAC安裝前的准備與規划開始進行整體介紹安裝部署Oracle RAC。始於唐博士指導，對數據庫集群進行配置安裝，前后經歷2，3個月的摸索。中間遇到不少問題。此文檔也將一一記錄整理。(本文原創/整理，轉載請標注原文出處:緩存融合技術和主要后台進程（四） )
2015年7月17日12:26:05
目錄
Cache Fusion 原理
前面已經介紹了 RAC 的后台進程，為了更深入的了解這些后台進程的工作原理，先了解一下 RAC 中多節點對共享數據文件訪問的管理是如何進行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 這個重要的概念，要發揮 Cache Fusion 的作用，要有一個前提條件，那就是互聯網絡的速度要比訪問磁盤的速度要快。否則，沒有引入 Cache Fusion 的意義。而事實上，現在 100MB 的互聯網都很常見。
什么是 Cache Fusion？
Cache Fusion 就是通過互聯網絡（高速的 Private interconnect）在集群內各節點的 SGA 之間進行塊傳遞，這是RAC最核心的工作機制，他把所有實例的SGA虛擬成一個大的SGA區，每當不同的實例請求相同的數據塊時，這個數據塊就通過 Private interconnect 在實例間進行傳遞。以避免首先將塊推送到磁盤，然后再重新讀入其他實例的緩存中這樣一種低效的實現方式(OPS 的實現)。當一個塊被讀入 RAC 環境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他實例知道該塊正在被使用。之后，如果另一個實例請求該塊的一個副本，而該塊已經處於前一個實例的緩存內，那么該塊會通過互聯網絡直接被傳遞到另一個實例的 SGA。如果內存中的塊已經被改變，但改變尚未提交，那么將會傳遞一個 CR 副本。這就意味着只要可能，數據塊無需寫回磁盤即可在各實例的緩存之間移動，從而避免了同步多實例的緩存所花費的額外 I/O。很明顯，不同的實例緩存的數據可以是不同的，也就是在一個實例要訪問特定塊之前，而它又從未訪問過這個塊，那么它要么從其他實例 cache fusion 過來，或者從磁盤中讀入。GCS（Global Cache Service，全局內存服務）和 GES（Global EnquenceService，全局隊列服務）進程管理使用集群節點之間的數據塊同步互聯。
這里還是有一些問題需要思考的：
- 在所有實例都未讀取該塊，而第一個實例讀取時，是怎么加的鎖，加的什么鎖？如果此時有另一個實例也要讀這個塊，幾乎是同時的，那么 Oracle 如何來仲裁，如何讓其中一個讀取，而另一個再從前者的緩存中通過 cache 來得到？
- 如果一個塊已經被其他實例讀入，那么本實例如何判斷它的存在？
- 如果某個實例改變了這個數據塊，是否會將改變傳遞到其他實例，或者說其他實例是否會知道並重新更新狀態？
- 如果一個實例要 swapout 某個塊，而同時其他實例也有這個塊的緩存，修改過的和未修改過的，本實例修改的和其他實例修改的，如何操作? truncate 一張表，drop 一張表... 和單實例有何不同？
- 應該如何設計應用，以使 RAC 真正發揮作用，而不是引入競爭，導致系統被削弱？
- RAC 下鎖的實現。
鎖是在各實例的 SGA 中保留的資源，通常被用於控制對數據庫塊的訪問。每個實例通常會保留或控制一定數量與塊范圍相關的鎖。當一個實例請求一個塊時，該塊必須獲得一個鎖，並且鎖必須來自當前控制這些鎖的實例。也就是鎖被分布在不同的實例上。而要獲得特定的鎖要從不同的實例上去獲得。但是從這個過程來看這些鎖不是固定在某個實例上的，而是根據鎖的請求頻率會被調整到使用最頻繁的實例上，從而提高效率。要實現這些資源的分配和重分配、控制，這是很耗用資源的。這也決定了 RAC 的應用設計要求比較高。假設某個實例崩潰或者某個實例加入，那么這里要有一個比較長的再分配資源和處理過程。在都正常運行的情況下會重新分配，以更加有效的使用資源；在實例推出或加入時也會重新分配。在 alert 文件中可以看到這些信息。而 Cache Fusion 及其他資源的分配控制，要求有一個快速的互聯網絡，所以要關注與互聯網絡上消息相關的度量，以測試互聯網絡的通信量和相應時間。對於前面的一些問題，可以結合另外的概念來學習，它們是全局緩存服務和全局隊列服務。
全局緩存服務(GCS):要和 Cache Fusion 結合在一起來理解。全局緩存要涉及到數據塊。全局緩存服務負責維護該全局緩沖存儲區內的緩存一致性，確保一個實例在任何時刻想修改一個數據塊時，都可獲得一個全局鎖資源，從而避免另一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象(post image)。如果另一個實例也請求該塊，那么全局緩存服務要負責跟蹤擁有該塊的實例、擁有塊的版本是什么，以及塊處於何種模式。LMS 進程是全局緩存服務的關鍵組成部分。
猜想：Oracle 目前的 cache fusion 是在其他實例訪問時會將塊傳輸過去再構建一個塊在那個實例的 SGA 中，這個主要的原因可能是 interconnect 之間的訪問還是從本地內存中訪問更快，從而讓 Oracle 再次訪問時可以從本地內存快速獲取。但是這也有麻煩的地方，因為在多個節點中會有數據塊的多個 copy，這樣在管理上的消耗是很可觀的，Oracle 是否會有更好的解決方案出現在后續版本中？如果 interconnect 速度允許的話...）
全局隊列服務(GES)：主要負責維護字典緩存和庫緩存內的一致性。字典緩存是實例的 SGA 內所存儲的對數據字典信息的緩存，用於高速訪問。由於該字典信息存儲在內存中，因而在某個節點上對字典進行的修改（如DDL)必須立即被傳播至所有節點上的字典緩存。GES 負責處理上述情況，並消除實例間出現的差異。處於同樣的原因，為了分析影響這些對象的 SQL 語句，數據庫內對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務必須確保請求訪問相同對象的多個實例間不會出現死鎖。LMON、LCK 和 LMD 進程聯合工作來實現全局隊列服務的功能。GES 是除了數據塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環境中調節節點間其他資源的重要服務。
SQL> select * from gv$sysstat where name like 'gcs %'
這里可以看到 gcs 和 ges 消息的發送個數。（如果沒有使用 DBCA 來創建數據庫，那么要 SYSDBA 權限來運行CATCLUST.SQL 腳本來創建 RAC 相關的視圖和表）
什么是高可用
Oracle failsafe、Data Guard 和 RAC 均為 ORACLE 公司提供的高可靠性（HA）解決方案。然而之三者之間卻存在着很大區別。HA 是 High Availability 的首字母組合，翻譯過來，可以叫做高可用，或高可用性，高可用（環境）。我覺得應該說 HA 是一個觀念而不是一項或一系列具體技術，就象網格一樣。作過系統方案就知道了，評價系統的性能當中就有一項高可用。也就是 OS 一級的雙機熱備。RAC 是 real application cluster 的簡稱，它是在多個主機上運行一個數據庫的技術，即是一個 db 多個 instance。它的好處是 可以由多個性能較差的機器構建出一個整體性能很好的集群，並且實現了負載均衡，那么當一個節點出現故障時，其上的服務會自動轉到另外的節點去執行，用戶甚 至感覺不到什么。
FAILSAFE 和 RAC 的區別
1、 操作系統：
failsafe 系統局限於 WINDOWS 平台，必須配合 MSCS（microsoft cluster server），而 RAC 最早是在 UNIX 平台推出的，目前已擴展至 LINUX 和 WINDOWS 平台，通過 OSD（operating system dependent）與系統交互。對於高端的 RAC 應用，UNIX 依然是首選的平台。
2、 系統結構：
FAILSAFE 采用的是 SHARE NOTHING 結構，即采用若干台服務器組成集群，共同連接到一個共享磁盤系統，在同一時刻，只有一台服務器能夠訪問共享磁盤，能夠對外提供服務。只要當此服務器失效時，才有另一台接管共享磁盤。RAC 則是采用 SHARE EVERYTHING，組成集群的每一台服務器都可以訪問共享磁盤，都能對外提供服務。也就是說 FAILSAFE 只能利用一台服務器資源，RAC 可以並行利用多台服務器資源。
3、 運行機理：
組成 FAILSAFE 集群的每台 SERVER 有獨立的 IP，整個集群又有一個 IP，另外還為 FAILSAFE GROUP 分配一個單獨的 IP（后兩個 IP 為虛擬 IP，對於客戶來說，只需知道集群 IP，就可以透明訪問數據庫）。工作期間，只有一台服務器（preferred or owner or manager）對外提供服務，其余服務器(operator)成待命狀，當前者失效時，另一服務器就會接管前者，包括FAILSAFE GROUP IP與CLUSTER IP，同時FAILSAFE會啟動上面的DATABASE SERVICE，LISTENER 和其他服務。客戶只要重新連接即可，不需要做任何改動。對於 RAC 組成的集群，每台服務器都分別有自已的 IP，INSTANCE 等，可以單獨對外提供服務，只不過它們都是操作位於共享磁盤上的同一個數據庫。當某台服務器失效后，用戶只要修改網絡配置，如（TNSNAMES。ORA），即可重新連接到仍在正常運行的服務器上。但和 TAF 結合使用時，甚至網絡也可配置成透明的。
4、 集群容量：
前者通常為兩台，后者在一些平台上能擴展至 8 台。
5、 分區：
FAILSAFE 數據庫所在的磁盤必須是 NTFS 格式的，RAC 則相對靈活，通常要求是 RAW，然而若干 OS 已操作出了 CLUSTER 文件系統可以供 RAC 直接使用。綜上所述，FAILSAFE 比較適合一個可靠性要求很高，應用相對較小，對高性能要求相對不高的系統，而 RAC則更適合可靠性、擴展性、性能要求都相對較高的較大型的應用。
RAC 和 OPS 區別
RAC 是 OPS 的后繼版本，繼承了 OPS 的概念，但是 RAC 是全新的，CACHE 機制和 OPS 完全不同。RAC 解決了 OPS 中 2 個節點同時寫同一個 BLOCK 引起的沖突問題。 從產品上來說 RAC 和 OPS 是完全不同的產品，但是我們可以認為是相同產品的不同版本
雙機熱備、RAC 和 Data Guard的區別
Data Guard 是 Oracle 的遠程復制技術，它有物理和邏輯之分，但是總的來說，它需要在異地有一套獨立的系統，這是兩套硬件配置可以不同的系統，但是這兩套系統的軟件結構保持一致，包括軟件的版本，目錄存儲結構，以及數據的同步（其實也不是實時同步的），這兩套系統之間只要網絡是通的就可以了，是一種異地容災的解決方案。而對於 RAC，則是本地的高可用集群，每個節點用來分擔不用或相同的應用，以解決運算效率低下，單節點故障這樣的問題，它是幾台硬件相同或不相同的服務器，加一個 SAN（共享的存儲區域）來構成的。Oracle 高可用性產品比較見下表：
節點間的通信（Interconnect）
通常在 RAC 環境下，在公用網絡的基礎上，需要配置兩條專用的網絡用於節點間的互聯，在 HACMP/ES 資源的定義中，這兩條專用的網絡應該被定義為"private" 。在實例啟動的過程中，RAC 會自動識別和使用這兩條專用的網絡，並且如果存在公用"public" 的網絡，RAC 會再識別一條公用網絡。當 RAC 識別到多條網絡時，RAC會使用 TNFF (Transparent Network Failvoer Failback) 功能，在 TNFF 下所有的節點間通信都通過第一條專用的網絡進行，第二條( 或第三條等) 作為在第一條專用的網絡失效后的備份。RAC 節點間通信如下圖所示。
CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一個可選的初始化(init.ora) 參數。此參數可以指定使用哪一條網絡用於節點間互聯通信，如果指定多條網絡，RAC 會在這些網絡上自動進行負載均衡。然而，當CLUSTER_INTERCONNECTS 設置時，TNFF 不起作用，這將降低 RAC 的可用性，任何一條節點間互聯網絡的失效，都會造成 RAC 一個或多個節點的失效。ORACLE RAC 用於 INTERCONNECT 的內網卡的物理連接方式的選擇：采用交換機連接或是網線直連。直連的弊端是，一旦一個節點機的內網卡出現故障，oracle 從 OS 得到兩個節點的網卡狀態都是不正常的，因而會導致兩個實例都宕掉。在 INTERCONNECT 線路出現問題的時候，oracle 一般情況下會啟動一個競爭機制來決定哪個實例宕掉，如果宕掉的實例正好是好的實例的話， 這樣就會導致兩個實例都宕掉。在 9i 中，oracle 在啟動競爭機制之前，會先等待一段時間，等待 OS 將網絡的狀態發給 oracle，如果在超時之前，oracle 獲得哪個實例的網卡是 down 的話，則將該實例宕掉，這樣的話，則可以保留正常的那個實例繼續服務，否則還是進入競爭機制。
綜上所述節點間通信分為兩種情況：
是接在交換機上面，此時一般情況下，是會保證正常的實例繼續服務的，但有的時候如果 os 來不及將網卡狀態送到 oracle 時，也是有可能會導致兩個節點都宕掉的。
如果是直連的話，則會導致兩個實例都宕掉。
CSS 心跳
OCSSD 這個進程是 Clusterware 最關鍵的進程，如果這個進程出現異常，會導致系統重啟，這個進程提供CSS(Cluster Synchronization Service)服務。 CSS 服務通過多種心跳機制實時監控集群狀態，提供腦裂保護等基礎集群服務功能。
CSS 服務有 2 種心跳機制： 一種是通過私有網絡的 Network Heartbeat，另一種是通過 Voting Disk 的 DiskHeartbeat。這 2 種心跳都有最大延時，對於 Disk Heartbeat，這個延時叫作 IOT (I/O Timeout);對於 Network Heartbeat, 這個延時叫 MC(Misscount)。這 2 個參數都以秒為單位，缺省時 IOT 大於 MC，在默認情況下，這 2 個參數是 Oracle自動判定的，並且不建議調整。可以通過如下命令來查看參數值：
$crsctl get css disktimeout
$crsctl get css misscount
Oracle RAC 節點間使用的通信協議見下表。
鎖
LOCK（鎖）是用來控制並發的數據結構，如果有兩個進程同時修改同一個數據， 為了防止出現混亂和意外，用鎖來控制訪問數據的次序。有鎖的可以先訪問，另外一個進程要等到第一個釋放了鎖，才能擁有鎖，繼續訪問。總體來說,RAC 里面的鎖分兩種， 一種是本地主機的進程之間的鎖，另外一種是不同主機的進程之間的鎖。本地鎖的機制有兩類，一類叫做 lock（鎖），另外一類叫做 latch 閂。
全局鎖就是指 RAC lock，就是不同主機之間的鎖，Oracle 采用了 DLM（Distributed Lock Management，分布式鎖管理）機制。在 Oracle RAC 里面，數據是全局共享的，就是說每個進程看到的數據塊都是一樣的，在不同機器間，數據塊可以傳遞。給出了 GRD目錄結構。
可以看出 Mode、Role、n 構成了 RAC lock 的基本結構
- Mode 有 N、S、X3 種方式
- Role 有 Local 和 Global 兩種
- N 有 PI 和 XI 兩種，一般 0 表示 XI，1 表示 PI
- 全局內存管理
- RAC 中的數據庫文件
- RAC 中讀的一致性
- 群集就緒服務（CRS）
- 全局資源目錄
一致性管理
數據一致性和並發性描述了 Oracle 如何維護多用戶數據庫環境中的數據一致性問題。在單用戶數據庫中，用戶修改數據庫中的數據，不用擔心其他用戶同時修改相同的數據。但是，在多用戶數據庫中，同時執行的多個事務中的語句可以修改同一數據。同時執行的事務需要產生有意義的和一致性的結果。因而，在多用戶數據庫中，數據並發性和數據一致性的控制非常重要：數據並發性：每個用戶可以看到數據的一致性結果。ANSI/IOS SQL 標准（SQL 92）定義了 4 個事務隔離級別，對事務處理性能的影響也個不相同。這些隔離級別是考慮了事務並發執行必須避免的 3 個現象提出的。3 個應該避免的現象為：
- 臟讀：一個事務可以讀取其他事務寫入但還沒有提交的數據。
- 不可重復讀（模糊讀）：一個事務重復讀到以前讀到的和查詢到的數據，這些數據是其他的已提交事務已經修改或者刪除的數據。
- 幻影讀：一個事務重復運行查詢返回的一些列行，這些行包括其他已經提交的事務已經插入的額外的行。
SQL92 根據這些對象定義了 4 個隔離級別，事務運行在特定的隔離級別允許特別的一些表現。如下表表示隔離級別阻止的讀現象。
OCR 結構
(一) OCR KEY 是樹形結構。
(二) OCR PROCESS 每個節點都有 OCR CACHE 的復制，由 ORC MASTER 節點負責更新到 OCR DISK
Oracle Clusterware 后台進程
自動啟動的腳本/etc/inittab 里定義：
OCSSD（Clustery Synchronization Service）提供心跳機制監控集群狀態
DISK HEARTBEAT
NETWORK HEARBEAT
CRSD（Clustery Ready Service）提供高可用、干預、關閉、重啟、轉移服務。
資源包括 nodeapps、database-related：前者每個節點只需要一個即可正常工作，后一個與數據庫相關，不受節點限制，可以為多個。
EVMD： 這個進程負責發布 CRS 產生的各種事件，還是 CRS 和 CSS 兩個服務之間通信的橋梁
RACGIMON： 這個進程負責檢查數據庫健康狀態，包括數據庫服務的啟動、停止和故障轉移。屬於持久連接，定期檢查 SGA。
OPROCD（Process Monitor Daemon）檢測 CPU hang（非 Linux 平台使用）
RAC 的並發控制
DLM 分布式鎖管理。
- Non-Cache Fusion 資源：包括數據文件、控制文件、數據字典視圖 、Library Cache、Row Cache
- Cache Fusion 資源：包括普通數據塊、索引數據塊、段頭、UNDO 數據塊。
- GRD（Global Resource Directory）：記錄每個數據塊在集群間的分布圖，在SGA中分master node與shadownode
- PCM lock：mode role Past Image
- LMS0（LOCK MANAGER SERVICE）：對應服務為 GCS（Global Cache Service），主要負責數據塊在實例間傳遞Cache fusion 參數 GCS_SERVER_PROCESSES
- LMD：對應服務為 GES（Global ENQUEUE Service），主要負責傳遞過程中鎖的管理。
- LCK：負責 NON-CACHE FUSION 資源同步訪問，每個實例有一個進程。
- LMON：這個進程定期通信每個實例，對應服務為 CGS（Cluster Group Service）。提供節點監控 node monitor，通過 GRD 中用位圖 0,1 來標志。0：節點關閉 1：節點正常運行通過 CM 層定期通信。
- 兩種心跳機制：網絡心跳和控制文件磁盤心跳 3S 一次。
- DIAG：監控狀態，寫日志 alert.log
- GSD：為用戶提供管理接口。
RAC 的主要后台進程
RAC 重構觸發條件
(一) NM（NODE MANAGEMENT）group
(二) 重構集群觸發：有 node 加入或者離開集群，由 NM 觸發 Network Heartbeat 異常：因為 LMON 或者 GCS、GES 通信異常 ，由 IMR（Instance Membership Reconfiguration）controlfile heartbeat 觸發。
RAC 優缺點
RAC 優點
(一) 多節點負載均衡
(二) 提供高可用性，故障容錯及無縫切換功能，將硬件和軟件的異常造成的影響最小化。
(三) 通過並行執行技術提供事務響應的時間 - 通常用於數據分析系統。
(四) 通過橫向擴展提高每秒交易數和連接數 - 通常用於 OLTP。
(五) 節約硬件成本，可以使用多個廉價的 PC 服務器代替小型機大型機，節約相應的維護成本。
(六) 可擴展性好，可以方便添加刪除節點，擴展硬件資源。
RAC 缺點
(一) 管理更復雜，要求更高
(二) 系統規划設計較差時性能可能會不如單節點
(三) 可能會增加軟件成本(按照 CPU 收費)
參考文獻
- Oracle的三種高可用集群方案
- 集群概念介紹：栢圖教育 Oracle 高級課程——理論教材
- Oracle 11 RAC生存指南
- Oracle 11gR2 RAC管理與性能優化
相關文章
【MySql集群搭建】 真機環境下MySQL-Cluster搭建文檔
【Hadoop集群搭建】Hadoop集群的配置（一）
【Hadoop集群搭建】Hadoop集群的配置（二）