要了解RAC工作原理的中心需要知道Cache Fusion這個重要概念，這個文章就是用來說明什么是Cache Fusion。要發揮Cache Fusion的作用，要有一個前提條件，那就是互聯網絡的速度要比訪問磁盤的速度要快！否則，沒有引入Cache Fusion的意義。而事實上，現在1000m的互聯都很常見。



什么是Cache Fusion?
Cache Fusion就是通過互聯網絡在集群內各節點的SGA之間進行塊傳遞，以避免首先將塊推送到磁盤，然后再重新讀入其他實例的緩存中這樣一種低效的實現方式(OPS的實現)。當一個塊被讀入RAC環境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他實例知道該塊正在被使用。之后，如果另一個實例請求該塊的一個副本，而該塊已經處于前一個實例的緩存內，那么該塊會通過互聯網絡直接被傳遞到另一個實例的SGA。如果內存中的塊已經被改變，但改變尚未提交，那么將會傳遞一個CR副本。這就意味著只要可能，數據塊無需寫回磁盤即可在各實例的緩存之間移動，從而避免了同步多實例的緩存所花費的額外I/O。很明顯，不同的實例緩存的數據可以是不同的，也就是在一個實例要訪問特定塊之前，而它又從未訪問過這個塊，那么它要么從其他實例cache fusion過來，或者從磁盤中讀入。

這里還是有一些問題需要思考的：
1、在所有實例都未讀取該塊，而第一個實例讀取時，是怎么加的鎖，加的什么鎖？如果此時有另一個實例也要讀這個塊，幾乎是同時的，那么Oracle如何來仲裁，如何讓其中一個讀取，而另一個再從前者的緩存中通過cache來得到？
2、如果一個塊已經被其他實例讀入，那么本實例如何判斷它的存在？
3、如果某個實例改變了這個數據塊，是否會將改變傳遞到其他實例，或者說其他實例是否會知道并重新更新狀態？
4、如果一個實例要swap out 某個塊，而同時其他實例也有這個塊的緩存，修改過的和未修改過的，本實例修改的和其他實例修改的，如何操作? truncate一張表，drop一張表... 和單實例有何不同？
5、應該如何設計應用，以使RAC真正發揮作用，而不是引入競爭，導致系統被削弱？
6、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> set linesize 1000
SQL> r
1* select * from gv$sysstat where name like 'gcs %'
INST_ID STATISTIC# NAME CLASS VALUE STAT_ID
---------- ---------- ------------------------------ ---------- ---------- ----------
1 44 gcs messages sent 32 5981 2765451804
2 44 gcs messages sent 32 3632 2765451804
SQL> select * from gv$sysstat where name like 'ges %';
INST_ID STATISTIC# NAME CLASS VALUE STAT_ID
---------- ---------- ------------------------------ ---------- ---------- ----------
1 45 ges messages sent 32 3760 1145425433
2 45 ges messages sent 32 4447 1145425433
SQL>
這里可以看到gcs和ges消息的發送個數。
（如果沒有使用DBCA來創建數據庫，那么要SYSDBA權限來運行CATCLUST.SQL腳本來創建RAC相關的視圖和表）


以后將更加深入的理解這些概念。
怎樣配制interconnect互聯網絡以保證高效運行？
1、硬件
2、參數設定
net.core.rmem_max最大的TCP數據接收緩沖

net.core.wmem_max
最大的TCP數據發送緩沖。
net.core.rmem_default
net.core.wmem_max 。

Cache Fusion
提供傳輸的擴展性，在實例間傳輸block 的image，跟蹤資源的當前位置和狀態，每個實例的sga的目錄結構中保存有資源信息

Cache Fusion模型

Global Resoure Directory由Global Cache Service 來管理
記錄資源的模式、資源的角色、block在實例中的狀態、在各個活動的節點發布資源的master、在必要的時候重新發布master（例如實例的啟動和關閉）

Global Cache Service
1、資源模式，三種
null (默認的)
share(s) (查詢)
exclusive(x) (可以改變block的內容,其它的實例就是null mode)
2、資源角色，兩種
local：
第一次請求資源的初試模式;只有一個實例可以有這個block的dirty copy
global：
當一個Block在多個實例中變dirty時，Local就變成了Global Block只能由Global Cache Service寫到磁盤中

Cache Fusion Block的傳輸

例如：有ABCD四個節點，Global Cache Service: GCS

1. Read with no transfer
如果C節點需要向共享磁盤文件上讀一個Block，那么它向Global Cache Service 發送請求，這個時候請求被定向到節點D，D是這個Block的Master(每個資源都有Master)。GCS把資源授權為Share Mode和Local Role，在目錄中記錄下了他的狀態(目錄在節點D)，然后通知C，C把這個資源從Null改成Share。C開始I/O，現在C有了這個Block以Share模式從磁盤文件讀取。
2. Read to write transfer
B也要這個Block，并且不僅是讀，而且還要改變它的內容。B向D(這個Block的Mater)的GCS發出請求，GCS向C發出請求，要求C把這個Block給B，C把Block給B，B收到后，告訴GCS，現在B可以修改這個block了。
3. Write to write transfer
A向D節點的GCS發出請求，GCS告訴B節點放棄他的Exclusive鎖，并且把當前的Image傳到A，如果這個請求沒有完成，就會放到GCS的隊列里。B把這個Block傳到A，這個時候，要寫Log，強制Lg Flush，把模式變成Null。發送到A，并且告訴它這個Exclusive的資源可以用了。A收到了這個Block的Image，會通知GCS并且告訴它Block的Status是Exclusive。這個時候，B不能對這個Block做操作，雖然在它的Buffer Cache中，它還有這個Block的Copy。
4. Write to read transfer
C要讀這個Block，先向D(Master)發出請求，GCS要求A把它傳輸到C，A接受到請求完成它的工作，這可能會在A寫Log和Log Flush在發送這個Block之前。A會把它的Exclusive鎖降低到Share模式。C把從A收到的Block的SCN取出來，建設成一個資源Assumption信息為GCS更新Global Resource Directory。

通過設置參數gc_files_to_locks，可以關閉Cache Fusion。這樣就象8i的OPS一樣，別的節點要訪問數據快，必須等待別的節點提交，寫回數據文件中。
Cache Resoure的Rematering
Cache Resoure在一個節點上不再需要繼續Master，Dynamic Remastering能把它移動到不同的節點。GCS和GES使用動態的Remastering：在一個新實例加入到這個Active Set之后重新分發資源，在一個實例離開這個Active Set之后重新分發資源。