CACHE FUSION 原理

前面已經(jīng)介紹了 RAC 的后臺進程，為了更深入的了解這些后臺進程的工作原理，先了解一下 RAC 中多節(jié)點對共享數(shù)據(jù)文件訪問的管理是如何進行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 這個重要的概念，要發(fā)揮 Cache Fusion 的作用，要有一個前提條件，那就是互聯(lián)網(wǎng)絡(luò)的速度要比訪問磁盤的速度要快。否則，沒有引入 CACHE FUSION 的意義。而事實上，現(xiàn)在 100MB 的互聯(lián)網(wǎng)都很常見。

什么是 CACHE FUSION？

Cache Fusion 就是通過互聯(lián)網(wǎng)絡(luò)（高速的 Private interconnect）在集群內(nèi)各節(jié)點的 SGA 之間進行塊傳遞，這是RAC最核心的工作機制，他把所有實例的SGA虛擬成一個大的SGA區(qū)，每當不同的實例請求相同的數(shù)據(jù)塊時，這個數(shù)據(jù)塊就通過 Private interconnect 在實例間進行傳遞。以避免首先將塊推送到磁盤，然后再重新讀入其他實例的緩存中這樣一種低效的實現(xiàn)方式(OPS 的實現(xiàn))。當一個塊被讀入 RAC 環(huán)境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他實例知道該塊正在被使用。之后，如果另一個實例請求該塊的一個副本，而該塊已經(jīng)處于前一個實例的緩存內(nèi)，那么該塊會通過互聯(lián)網(wǎng)絡(luò)直接被傳遞到另一個實例的 SGA。如果內(nèi)存中的塊已經(jīng)被改變，但改變尚未提交，那么將會傳遞一個 CR 副本。這就意味著只要可能，數(shù)據(jù)塊無需寫回磁盤即可在各實例的緩存之間移動，從而避免了同步多實例的緩存所花費的額外 I/O。很明顯，不同的實例緩存的數(shù)據(jù)可以是不同的，也就是在一個實例要訪問特定塊之前，而它又從未訪問過這個塊，那么它要么從其他實例 cache fusion 過來，或者從磁盤中讀入。GCS（Global Cache Service，全局內(nèi)存服務(wù)）和 GES（Global EnquenceService，全局隊列服務(wù)）進程管理使用集群節(jié)點之間的數(shù)據(jù)塊同步互聯(lián)。

這里還是有一些問題需要思考的：

• 在所有實例都未讀取該塊，而第一個實例讀取時，是怎么加的鎖，加的什么鎖？如果此時有另一個實例也要讀這個塊，幾乎是同時的，那么 Oracle 如何來仲裁，如何讓其中一個讀取，而另一個再從前者的緩存中通過 cache 來得到？
• 如果一個塊已經(jīng)被其他實例讀入，那么本實例如何判斷它的存在？
• 如果某個實例改變了這個數(shù)據(jù)塊，是否會將改變傳遞到其他實例，或者說其他實例是否會知道并重新更新狀態(tài)？
• 如果一個實例要 swap out 某個塊，而同時其他實例也有這個塊的緩存，修改過的和未修改過的，本實例修改的和其他實例修改的，如何操作? truncate 一張表，drop 一張表... 和單實例有何不同？
• 應(yīng)該如何設(shè)計應(yīng)用，以使 RAC 真正發(fā)揮作用，而不是引入競爭，導(dǎo)致系統(tǒng)被削弱？
• RAC 下鎖的實現(xiàn)。

鎖是在各實例的 SGA 中保留的資源，通常被用于控制對數(shù)據(jù)庫塊的訪問。每個實例通常會保留或控制一定數(shù)量與塊范圍相關(guān)的鎖。當一個實例請求一個塊時，該塊必須獲得一個鎖，并且鎖必須來自當前控制這些鎖的實例。也就是鎖被分布在不同的實例上。而要獲得特定的鎖要從不同的實例上去獲得。但是從這個過程來看這些鎖不是固定在某個實例上的，而是根據(jù)鎖的請求頻率會被調(diào)整到使用最頻繁的實例上，從而提高效率。要實現(xiàn)這些資源的分配和重分配、控制，這是很耗用資源的。這也決定了 RAC 的應(yīng)用設(shè)計要求比較高。假設(shè)某個實例崩潰或者某個實例加入，那么這里要有一個比較長的再分配資源和處理過程。在都正常運行的情況下會重新分配，以更加有效的使用資源；在實例推出或加入時也會重新分配。在 alert 文件中可以看到這些信息。而 Cache Fusion 及其他資源的分配控制，要求有一個快速的互聯(lián)網(wǎng)絡(luò)，所以要關(guān)注與互聯(lián)網(wǎng)絡(luò)上消息相關(guān)的度量，以測試互聯(lián)網(wǎng)絡(luò)的通信量和相應(yīng)時間。對于前面的一些問題，可以結(jié)合另外的概念來學(xué)習(xí)，它們是全局緩存服務(wù)和全局隊列服務(wù)。

全局緩存服務(wù)(GCS):要和 Cache Fusion 結(jié)合在一起來理解。全局緩存要涉及到數(shù)據(jù)塊。全局緩存服務(wù)負責(zé)維護該全局緩沖存儲區(qū)內(nèi)的緩存一致性，確保一個實例在任何時刻想修改一個數(shù)據(jù)塊時，都可獲得一個全局鎖資源，從而避免另一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象(post image)。如果另一個實例也請求該塊，那么全局緩存服務(wù)要負責(zé)跟蹤擁有該塊的實例、擁有塊的版本是什么，以及塊處于何種模式。LMS 進程是全局緩存服務(wù)的關(guān)鍵組成部分。

猜想：Oracle 目前的 cache fusion 是在其他實例訪問時會將塊傳輸過去再構(gòu)建一個塊在那個實例的 SGA 中，這個主要的原因可能是 interconnect 之間的訪問還是從本地內(nèi)存中訪問更快，從而讓 Oracle 再次訪問時可以從本地內(nèi)存快速獲取。但是這也有麻煩的地方，因為在多個節(jié)點中會有數(shù)據(jù)塊的多個 copy，這樣在管理上的消耗是很可觀的，Oracle 是否會有更好的解決方案出現(xiàn)在后續(xù)版本中？如果 interconnect 速度允許的話...）

全局隊列服務(wù)(GES)：主要負責(zé)維護字典緩存和庫緩存內(nèi)的一致性。字典緩存是實例的 SGA 內(nèi)所存儲的對數(shù)據(jù)字典信息的緩存，用于高速訪問。由于該字典信息存儲在內(nèi)存中，因而在某個節(jié)點上對字典進行的修改（如DDL)必須立即被傳播至所有節(jié)點上的字典緩存。GES 負責(zé)處理上述情況，并消除實例間出現(xiàn)的差異。處于同樣的原因，為了分析影響這些對象的 SQL 語句，數(shù)據(jù)庫內(nèi)對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務(wù)必須確保請求訪問相同對象的多個實例間不會出現(xiàn)死鎖。LMON、LCK 和 LMD 進程聯(lián)合工作來實現(xiàn)全局隊列服務(wù)的功能。GES 是除了數(shù)據(jù)塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環(huán)境中調(diào)節(jié)節(jié)點間其他資源的重要服務(wù)。

SQL> select * from gv$sysstat where name like 'gcs %'

http://wiki.jikexueyuan.com/project/oraclecluster/images/7.png" alt="" />

這里可以看到 gcs 和 ges 消息的發(fā)送個數(shù)。（如果沒有使用 DBCA 來創(chuàng)建數(shù)據(jù)庫，那么要 SYSDBA 權(quán)限來運行CATCLUST.SQL 腳本來創(chuàng)建 RAC 相關(guān)的視圖和表）

什么是高可用

Oracle failsafe、Data Guard 和 RAC 均為 ORACLE 公司提供的高可靠性（HA）解決方案。然而之三者之間卻存在著很大區(qū)別。

HA 是 High Availability 的首字母組合，翻譯過來，可以叫做高可用，或高可用性，高可用（環(huán)境）。我覺得應(yīng)該說 HA 是一個觀念而不是一項或一系列具體技術(shù)，就象網(wǎng)格一樣。作過系統(tǒng)方案就知道了，評價系統(tǒng)的性能當中就有一項高可用。也就是 OS 一級的雙機熱備。RAC 是 real application cluster 的簡稱，它是在多個主機上運行一個數(shù)據(jù)庫的技術(shù)，即是一個 db 多個 instance。它的好處是 可以由多個性能較差的機器構(gòu)建出一個整體性能很好的集群，并且實現(xiàn)了負載均衡，那么當一個節(jié)點出現(xiàn)故障時，其上的服務(wù)會自動轉(zhuǎn)到另外的節(jié)點去執(zhí)行，用戶甚 至感覺不到什么。

FAILSAFE 和 RAC 的區(qū)別

操作系統(tǒng)

failsafe 系統(tǒng)局限于 WINDOWS 平臺，必須配合 MSCS（microsoft cluster server），而 RAC 最早是在 UNIX 平臺推出的，目前已擴展至 LINUX 和 WINDOWS 平臺，通過 OSD（operating system dependent）與系統(tǒng)交互。對于高端的 RAC 應(yīng)用，UNIX 依然是首選的平臺。

系統(tǒng)結(jié)構(gòu)

FAILSAFE 采用的是 SHARE NOTHING 結(jié)構(gòu)，即采用若干臺服務(wù)器組成集群，共同連接到一個共享磁盤系統(tǒng)，在同一時刻，只有一臺服務(wù)器能夠訪問共享磁盤，能夠?qū)ν馓峁┓?wù)。只要當此服務(wù)器失效時，才有另一臺接管共享磁盤。RAC 則是采用 SHARE EVERYTHING，組成集群的每一臺服務(wù)器都可以訪問共享磁盤，都能對外提供服務(wù)。也就是說 FAILSAFE 只能利用一臺服務(wù)器資源，RAC 可以并行利用多臺服務(wù)器資源。

運行機理

組成 FAILSAFE 集群的每臺 SERVER 有獨立的 IP，整個集群又有一個 IP，另外還為 FAILSAFE GROUP 分配一個單獨的 IP（后兩個 IP 為虛擬 IP，對于客戶來說，只需知道集群 IP，就可以透明訪問數(shù)據(jù)庫）。工作期間，只有一臺服務(wù)器（preferred or owner or manager）對外提供服務(wù)，其余服務(wù)器(operator)成待命狀，當前者失效時，另一服務(wù)器就會接管前者，包括FAILSAFE GROUP IP與CLUSTER IP，同時FAILSAFE會啟動上面的DATABASE SERVICE，LISTENER 和其他服務(wù)。客戶只要重新連接即可，不需要做任何改動。對于 RAC 組成的集群，每臺服務(wù)器都分別有自已的 IP，INSTANCE 等，可以單獨對外提供服務(wù)，只不過它們都是操作位于共享磁盤上的同一個數(shù)據(jù)庫。當某臺服務(wù)器失效后，用戶只要修改網(wǎng)絡(luò)配置，如（TNSNAMES。ORA），即可重新連接到仍在正常運行的服務(wù)器上。但和 TAF 結(jié)合使用時，甚至網(wǎng)絡(luò)也可配置成透明的。

集群容量

前者通常為兩臺，后者在一些平臺上能擴展至 8 臺。

分區(qū)

FAILSAFE 數(shù)據(jù)庫所在的磁盤必須是 NTFS 格式的，RAC 則相對靈活，通常要求是 RAW，然而若干 OS 已操作出了 CLUSTER 文件系統(tǒng)可以供 RAC 直接使用。

綜上所述，F(xiàn)AILSAFE 比較適合一個可靠性要求很高，應(yīng)用相對較小，對高性能要求相對不高的系統(tǒng)，而 RAC則更適合可靠性、擴展性、性能要求都相對較高的較大型的應(yīng)用。

RAC 和 OPS 區(qū)別

RAC 是 OPS 的后繼版本，繼承了 OPS 的概念，但是 RAC 是全新的，CACHE 機制和 OPS 完全不同。RAC 解決了 OPS 中 2 個節(jié)點同時寫同一個 BLOCK 引起的沖突問題。 從產(chǎn)品上來說 RAC 和 OPS 是完全不同的產(chǎn)品，但是我們可以認為是相同產(chǎn)品的不同版本

　雙機熱備、RAC 和 DATA GUARD　的區(qū)別

Data Guard 是 Oracle 的遠程復(fù)制技術(shù)，它有物理和邏輯之分，但是總的來說，它需要在異地有一套獨立的系統(tǒng)，這是兩套硬件配置可以不同的系統(tǒng)，但是這兩套系統(tǒng)的軟件結(jié)構(gòu)保持一致，包括軟件的版本，目錄存儲結(jié)構(gòu)，以及數(shù)據(jù)的同步（其實也不是實時同步的），這兩套系統(tǒng)之間只要網(wǎng)絡(luò)是通的就可以了，是一種異地容災(zāi)的解決方案。而對于 RAC，則是本地的高可用集群，每個節(jié)點用來分擔(dān)不用或相同的應(yīng)用，以解決運算效率低下，單節(jié)點故障這樣的問題，它是幾臺硬件相同或不相同的服務(wù)器，加一個 SAN（共享的存儲區(qū)域）來構(gòu)成的。

Oracle 高可用性產(chǎn)品比較見下表：

http://wiki.jikexueyuan.com/project/oraclecluster/images/8.png" alt="" />

節(jié)點間的通信（INTERCONNECT）

通常在 RAC 環(huán)境下，在公用網(wǎng)絡(luò)的基礎(chǔ)上，需要配置兩條專用的網(wǎng)絡(luò)用于節(jié)點間的互聯(lián)，在 HACMP/ES 資源的定義中，這兩條專用的網(wǎng)絡(luò)應(yīng)該被定義為"private" 。在實例啟動的過程中，RAC 會自動識別和使用這兩條專用的網(wǎng)絡(luò)，并且如果存在公用"public" 的網(wǎng)絡(luò)，RAC 會再識別一條公用網(wǎng)絡(luò)。當 RAC 識別到多條網(wǎng)絡(luò)時，RAC 會使用 TNFF (Transparent Network Failvoer Failback) 功能，在 TNFF 下所有的節(jié)點間通信都通過第一條專用的網(wǎng)絡(luò)進行，第二條( 或第三條等) 作為在第一條專用的網(wǎng)絡(luò)失效后的備份。RAC 節(jié)點間通信如下圖所示。

http://wiki.jikexueyuan.com/project/oraclecluster/images/9.png" alt="" />

CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一個可選的初始化(init.ora) 參數(shù)。此參數(shù)可以指定使用哪一條網(wǎng)絡(luò)用于節(jié)點間互聯(lián)通信，如果指定多條網(wǎng)絡(luò)，RAC 會在這些網(wǎng)絡(luò)上自動進行負載均衡。然而，當CLUSTER_INTERCONNECTS 設(shè)置時，TNFF 不起作用，這將降低 RAC 的可用性，任何一條節(jié)點間互聯(lián)網(wǎng)絡(luò)的失效，都會造成 RAC 一個或多個節(jié)點的失效。ORACLE RAC 用于 INTERCONNECT 的內(nèi)網(wǎng)卡的物理連接方式的選擇：采用交換機連接或是網(wǎng)線直連。直連的弊端是，一旦一個節(jié)點機的內(nèi)網(wǎng)卡出現(xiàn)故障，oracle 從 OS 得到兩個節(jié)點的網(wǎng)卡狀態(tài)都是不正常的，因而會導(dǎo)致兩個實例都宕掉。在 INTERCONNECT 線路出現(xiàn)問題的時候，oracle 一般情況下會啟動一個競爭機制來決定哪個實例宕掉，如果宕掉的實例正好是好的實例的話， 這樣就會導(dǎo)致兩個實例都宕掉。在 9i 中，oracle 在啟動競爭機制之前，會先等待一段時間，等待 OS 將網(wǎng)絡(luò)的狀態(tài)發(fā)給 oracle，如果在超時之前，oracle 獲得哪個實例的網(wǎng)卡是 down 的話，則將該實例宕掉，這樣的話，則可以保留正常的那個實例繼續(xù)服務(wù)，否則還是進入競爭機制。

綜上所述節(jié)點間通信分為兩種情況：

• 是接在交換機上面，此時一般情況下，是會保證正常的實例繼續(xù)服務(wù)的，但有的時候如果 os 來不及將網(wǎng)卡狀態(tài)送到 oracle 時，也是有可能會導(dǎo)致兩個節(jié)點都宕掉的。
• 如果是直連的話，則會導(dǎo)致兩個實例都宕掉。

CSS 心跳

OCSSD 這個進程是 Clusterware 最關(guān)鍵的進程，如果這個進程出現(xiàn)異常，會導(dǎo)致系統(tǒng)重啟，這個進程提供CSS(Cluster Synchronization Service)服務(wù)。 CSS 服務(wù)通過多種心跳機制實時監(jiān)控集群狀態(tài)，提供腦裂保護等基礎(chǔ)集群服務(wù)功能。

CSS 服務(wù)有 2 種心跳機制： 一種是通過私有網(wǎng)絡(luò)的 Network Heartbeat，另一種是通過 Voting Disk 的 DiskHeartbeat。這 2 種心跳都有最大延時，對于 Disk Heartbeat，這個延時叫作 IOT (I/O Timeout);對于 Network Heartbeat, 這個延時叫 MC(Misscount)。這 2 個參數(shù)都以秒為單位，缺省時 IOT 大于 MC，在默認情況下，這 2 個參數(shù)是 Oracle自動判定的，并且不建議調(diào)整?？梢酝ㄟ^如下命令來查看參數(shù)值：

$crsctl get css disktimeout
$crsctl get css misscount

Oracle RAC 節(jié)點間使用的通信協(xié)議見下表。

http://wiki.jikexueyuan.com/project/oraclecluster/images/10.png" alt="" />