Cache Fusion （緩存融合）
實際意義上講就是通過互連網絡在集羣各個節點內的SGA之間進行塊傳遞，這樣做的好處是避免多次將塊寫入磁盤，再重新讀入到其他實例的緩存中。當一個塊從磁盤讀入RAC環境中的首個實例的sga中，該塊會被賦予一個鎖資源（區別於行級鎖），以讓其他實例知道該塊正在被使用（或是讀），當另一個實例請求該塊的操作時，當前實例sga會傳遞一個塊的副本給另一個實例（該塊爲最新，並未改變）；如果內存中的塊已經被改變，但改變尚未提交，會傳遞一個CR副本，並改變相應的鎖資源的級別。從本質上講，數據庫無需多次寫回磁盤或從磁盤多次讀入相關實例們的sga中，在各實例中的緩存中實現共享和傳遞，從而避免同步實例緩存所花費的額外i/o。
應用環境：當互連網絡速度遠遠大於磁盤I/O訪問速度。
下面是cache fusion中一些概念的介紹
全局緩存服務(GCS):全局緩存（SGA）要涉及到數據塊。全局緩存服務負責維護該全局緩衝存儲區內的緩存一致性，確保一個實例在任何時刻想修改一個數據塊時，都可獲得一個全局鎖資源，從而避免另一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前CP版本（包括已提交的和未提交的事物）以及塊的前象(post image)。如果另一個實例也請求該塊，那麼GCS要負責跟蹤擁有該塊的實例、擁有塊的版本是什麼，以及塊處於何種資源模式。LMS進程是全局緩存服務的關鍵組成部分。（LMS爲鎖管理服務器進程，爲cache fusion請求在實例間的傳遞服務）
全局隊列服務(GES)：主要負責維護字典緩存和庫緩存內的一致性。字典緩存是實例的SGA內所存儲的對數據字典信息的緩存，用於高速訪問。由於該字典信息存儲在內存中，因而在某個節點上對字典進行的修改（如DDL)必須立即被傳播至所有節點上的字典緩存。GES負責處理上述情況，並消除實例間出現的差異。處於同樣的原因，爲了分析影響這些對象的SQL語句，數據庫內對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務必須確保請求訪問相同對象的多個實例間不會出現死鎖。LMON、LCK和LMD進程聯合工作來實現全局隊列服務的功能。GES是除了數據塊本身的維護和管理（由GCS完成）之外，在RAC環境中調節節點間其他資源的重要服務。
1.資源模式：三種
null (默認的)
share(S) (查詢)
exclusive(X) (修改block的內容,其它的實例就爲null mode)
2.資源角色：兩種
local：
第一次請求資源的初試模式;只有一個實例可以有這個block的dirty copy(即磁盤數據塊的元數據內容)
global：
當一個Block在多個實例中變dirty時，Local就變成了Global 並最終只能由GCS發送請求寫到磁盤中
下面說下 cache fusion block 是如何傳輸的。
環境：A,B,C,D四個節點，實例D有擁有數據塊的MASTER資源權限（每個數據塊都擁有一個master）
Read from no transfer
假設，四個實例的sga從未緩存過該數據塊，如果節點C需要向shared data disk 讀一個block。 則節點C向GCS發送請求，此時請求被指向節點D（因爲節點D是數據塊的master），GCS把該塊的資源改爲share mode（S）和local role 並在D節點的GCS記錄狀態，並通知，C的GCS把此資源模式從Null->Share C開始I/O讀磁盤讀取該塊。
Read to Write transfer
B要讀寫這個數據塊，B的GCS向D發出請求，D的GCS向C發出請求，要求C把數據塊給B，C把數據塊CP傳給B，B的GCS修改塊的模式Null->Exclusive（X） 且其他節點的模式爲->null
Write to Write transfer
A節點也要修改數據塊，A的GCS向D發出請求，D的GCS指向B，如果此時該請求還沒完成，則放到GES隊列中，B取消修改並把block傳給A （此時會強制log flush）b的塊模式變爲null A收到塊後加X鎖， 此時，雖然B有塊的cp，但不能修改，因爲b塊模式爲null
Write to Read transfer
C要讀block，C的GCS向D發送請求，D指向A，A把該塊的鎖由X->Share模式，C收到A的塊CP 取出SCN,由GCS更新元數據塊CP的SCN。
通過設置參數gc_files_to_locks，可以關閉Cache Fusion。
關閉後，則別的節點要讀/寫數據塊時，必須等待佔用該塊的實例節點提交，寫回數據文件中。
注1：當有新的節點添加/崩潰時，原節點的鎖資源會重新平衡
注2：當一個節點不再需要master，動態資源控制進程會把他移到請求頻率最高的一個節點上