【RAC原理】Cache Fusion

要了解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之後重新分發資源。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29319205/viewspace-1248701/，如需轉載，請註明出處，否則將追究法律責任。