Cache Fusion (1)

這兩天學習了RAC的Cache Fusion，整理一下，年前最後的筆記。

RAC環境下，每個執行個體都有其本地buffer cache， 與單一實例DB中一樣完成其工作。但是會存在執行個體A需要某個資料區塊而這個資料區塊正在被執行個體B操作，這種情況下，需要通過互聯(Interconnect)機制訪問，就是Cache Fusion。

Cache Fusion通過共用快取(Cache)解決並發問題。在Cache Fusion演算法中，當一個執行個體請求修改資料區塊時候，當前正在修改該資料區塊的執行個體不需要寫入磁碟，減少了磁碟寫操作I/O開銷。Cache Fusion的並發控制極大的改善了資料庫效能，減少了RAC環境中的更多的管理。

 

先來介紹幾個定義吧：

GCS (Global Cache Service) 全域快取服務： 是在多個緩衝中維持緩衝一致性(cache coherency)的主要機制，它是Cache Fusion的核心概念，當一個執行個體需要訪問某一資料區塊時候，會向GCS發起請求。後台進程LMS

        Tracking：跟蹤資料區塊；跟蹤隊列機制中的所有狀態

        Accepting：接受資料區塊請求；

        Informing：通知持有資源的執行個體釋放資料區塊上的鎖或者發送CR image；通知執行個體持有或者情況PI

        Coordinating：通過interconnect 協調資料區塊在不同執行個體之間轉寄

GES (Global Enqueue Service) 全域佇列服務，通過管理字典緩衝鎖，Library Cache鎖和事務來實現被多個執行個體使用的資源的並發，包括：

          事務鎖(Transaction locks) – 排它模式，事務提交或者復原後才會釋放。

          Library Cache locks - 解析和編譯SQL,DML, DDL,PL/SQL, Java語句時引用資料庫物件(表，視圖，過程，函數，包，包體，觸發器，索引，簇，同義字)  需要該鎖。

          字典緩衝鎖(Dictionary Cache Locks) -  RAC中，oracle會在整個叢集中同步所有的字典緩衝，使用的是latches。

          表級鎖(Table locks)  – null (N), row share (RS), row exclusive (RX), share lock (S), share row exclusive (SRX), or exclusive (X).

GRD (Global Resource Dictionary) 全域資來源目錄，由GCS和GES共同維護(可以看做一個記憶體資料庫)，儲存當前緩衝中的塊資訊(資料區塊地址，最新版本所在執行個體，Mode，Role，SCN，PI)。

GRD記錄了最新的資料庫所在位置，塊模式(Mode)和角色(Role)，cache fusion 中所有資源請求和轉寄都儲存在GRD中。GRD是分布式資源，儲存在SGA中，每個執行個體中都包含一部分GRD資源。  

模式(Mode)和角色(Role)資訊有GCS在GRD中維護。

GRD資源的Mode有三種：Null (N) Mode，Shared (S) Mode，Exclusive (X) Mode

          Null (N) Mode

          Shared (S) Mode：共用模式表明當前執行個體會話對資料區塊讀而沒有修改

          Exclusive (X) Mode：獨佔模式表明不可以被其他執行個體修改，當前執行個體會話獨佔該資料區塊，該資料庫可以被一致讀。

GRD資源的Role有三種：Local，Global

          Local：資料庫首次被讀入記憶體，只有一個該資料區塊的鏡像。

          Global：髒緩衝在持有資源的執行個體(holding instance)上(PI)，發送到新請求的執行個體(requesting instance)中，這時候需要Global角色。

綜上，可以用SL0表示Shared mode, Local role, 0 PI

PI  (Past Image) 陳像，是資料區塊寫入磁碟之前的儲存在buffer cache中的資料區塊鏡像，出現在寫-寫並發中。

執行個體A讀取資料區塊D1入A的buffer cache，執行個體B也想讀取資料區塊D1，cache fusion 中，執行個體A將把D1傳送到B，此時，在A的buffer cache中的D1就成為一個“陳像”。之所以稱之為“陳像”，是因為當前最後請求訪問的是執行個體B，B可能對D1做修改，而一旦修改了，在A中的D1的PI就不再是最新版本，也就是一個“陳像”(髒緩衝塊)了。

Cache fusion優勢在於多執行個體並發訪問同一資料區塊時候，不需要等待當前執行個體完成磁碟寫入就可以把該資料區塊連帶被該執行個體修改但尚未寫入磁碟的內容一併直接從buffer cache中copy到另一個執行個體，這樣多個執行個體並發就會在多個執行個體上存在不同版本的PI了。

這些不同版本的PI可以在某個執行個體宕掉的時候做恢複使用。

當資料區塊修改被寫入磁碟時候，所有執行個體上的所有PI就會被清理掉，redo log裡與該PI相關的log也可以被覆蓋掉了。

CR Image 一致讀鏡像，出現在讀-寫並發中。

PI是儲存在持有資源的執行個體(holding instance)的buffer cache裡的，而CR image需要發送到新請求的執行個體(requesting instance)中。

先來瞭解一下一致性讀(Consistent Read)

事務T1正在修改D1，事務T2想要讀取D1；如果T1還沒有commit，T2就需要一個CR塊。CR塊是根據SCN從undo segment/buffer中讀取的髒資料區塊。

在RAC中，由於需要訪問不同執行個體上的undo segment，建立CR image會產生額外的I/O開銷。

 

整理這些就用了一下午，看了好多文檔，blog，依靠強大的網路學到了知識，所以也希望多少貢獻一點點，希望能有用。

其實，看的越多，發現懂得越少了。。

明天不忙的話把Cache fusion的使用情境列一下。

發現了一本好書，打個廣告吧，O(∩_∩)O~，五百多，怎麼說也有點貴呀。

Oracle 10g Grid & Real Application Clusters
Oracle10g Grid Computing with RAC

Mike Ault, Madhu Tumma  

 

【參考文檔】：

1. http://www.dba-oracle.com/t_gupta_oracle_rac_cache_fusion.htm

2. http://avdeo.com/2008/07/21/oracle-rac-10g-cache-fusion/

3.

http://www.remote-dba.net/t_rac_real_application_clusters_components.htm

4. http://www.manotes.net/?p=213

5. http://docs.oracle.com/cd/B10501_01/rac.920/a96597/pslkgdtl.htm