【微信公眾號】【深入解析】DRM和read-mostly locking

何劍敏 

Oracle ACS華南區售後團隊，首席技術工程師。多年從事第一線的資料庫運維工作，有豐富專案經驗、維護經驗和調優經驗，專注於資料庫的整體運維。

1瞭解DRM（Dynamic Resource Remastering）

講DRM（Dynamic Resource Remastering），首先一定說說cache fusion的機制，cache fusion是在8i OPS中引入，解決的目的是原來在OPS中，instance A讀某個block，instance B也要讀時，instance A必須把該block寫入到磁碟，然後由instance B從磁碟讀取。當時在8i中引入cache fusion，使得“讀”能跨節點的“讀”，但是“寫”（或者說修改），還是要寫入到磁碟，再在另一個節點讀出來，然後修改。

在9i中，“寫”得到了改進，髒塊也能跨節點的傳輸。這就是常說的Write / Write Cache Fusion。

10gR1引入DRM，但當時的DRM功能很有限，只有在instance變化的時候（如instance被踢出叢集，instance加入叢集）才進行資源的remastering。

10gR2引入Affinity Locks和Object級別的DRM。

11g引入Read-Mostly和Reader Bypass

2DRM的實現依賴以下的功能：

1、Read-mostly locking

【原理】11g的DRM引入了read mostly locking的機制，它會基於物件的global operation歷史。

read mostly locking機制，能減少讀訪問的訊息傳遞和CPU消耗，但是寫訪問就會比傳統的cache fusion locking機制消耗更多的IO。

oracle的cache層記錄著每個物件上的S lock和X lock的數量，如果某個節點開啟了大量的S lock並且很少了的X lock，並且block傳輸的比較少，那麼這個物件在這個節點上就是read mostly了。當read mostly發生的時候，物件的共享就停止了，並且block不再透過interconnect進行傳輸（除非block被修改）。

當一個物件被定義成read mostly，他會被master node授予在所有節點上的S affinity lock，這意味著所有的節點都被“提前”授予了該block的讀訪問許可權，因此，減少了在各個節點間互相傳遞S lock的訊息量。

Oracle使用一種特殊的叫anti-lock，來控制read mostly物件上的X鎖。當x lock被申請時，所有的節點會被廣播通知到要開啟anti-lock，，在anti-lock的淫威之下，所有的對那個塊的訪問（不管是S lock還是X lock）都會變成標準的cache fusion locking，即使該物件本身還是read-mostly。廣播會在分配X lock之前完成，僅當block上沒有anti-lock開啟的時候。anti-lock將會在read-mostly消失的時候，或者髒塊寫入磁碟的時候清除掉，並且X lock會降級。

為read-mostly的物件開啟x lock是非常昂貴的操作，在分配x lock之前，master node需要廣播anti-lock給所有的節點。在x lock關閉之前，anti-lock不能被移除。另外，在節點加入叢集的時候，他也會建立anti-lock，anti-lock只是在LE上標記KCLL_F_ANTI，並且在有anti-lock的情況下，read-mostly lock不能被分配。

【效能優勢】在讀居多的情況下，由於減少了訊息傳遞，因此"gc cr grant 2-way", "gc current block 2-way" and "gc current block 3-way"的等待大大減少，但是你會看到"db file sequential read"的等待有所增多，因為不在記憶體間傳輸block塊，而改成去物理檔案讀取了。GCS訊息傳遞和block transfer的統計值也大大減少了。

在寫居多的情況下，X lock的請求會增加，anti-lock廣播的次數也會增多，此時"gc current grant busy"的等待就會增加，因為GCS的訊息傳遞增加了。 另外，由於開啟anti-lock的block的行為都會變成傳統的cache fusion的行為，你將又能看到一些2-way grant和block transfer的等待了。

由於減少分配S lock，只要在讀居多的情況下（即X lock申請量不多的情況下），cluster還是很能從read-mostly特性中得到好處的。

這是因為在節點數多的情況下，遠端分配的機會將會大大增加。這意味著利用read-mostly將能減少訊息傳遞。另一方面，當節點增加時，X lock的請求將會增多，這是因為X lock的請求會傳播到每個節點，當節點數增加的時候，訊息傳遞的成本也增加了。

總而言之，clsuster將會在節點數多，且X lock請求少的情況，因為read-mostly特性而收益。但是當X lock請求增加的事情，效能會急劇的降低。從另一方面說，如果你的節點數比較少，那麼或許你從read mostly特性那裡得不到很多好處。

而由於read mostly會消耗比較多的IO，這個時候你就要估計你一下你的IO情況了，如果你的塊和訊息傳遞的收益小於IO負載變重的情況，或者你已經處於IO壓力很大的情況下，那麼，就不建議你開啟read mostly的特性了，你可以禁用read mostly的特性。設定方式是：_gc_read_mostly_locking=FALSE

因此，read-mostly的特性是給那些讀很多，寫很少的系統來啟用比較合適。

【read-mostly的過渡】

oracle的cache層保留著每個object的x/s lock的請求統計資訊，他會根據統計資訊，自動初始化或者捨棄read-mostly。這種過渡和affinity很相像，透過標準DRM協議。當cache層看到太多anti-lock的時候，read-mostly將會被捨棄。當read-mostly的負載突然變成大量的寫的負載的時候，大量的anti-lock增加的時候，這種過渡就會發生了。舉例來說，就是當一個大量被read-mostly的表，進行了大量的update操作的時候，這種過渡就發生了。

2、Object affinity

說實在的，我一直不知道affinity這個詞該怎麼翻譯，親和力？吸引力？我們姑且把它叫做物件吸引吧。

在預設的情況下，即當沒有吸引機制或者read-mostly策略生效的情況下，buffer cache的資源master許可權是會被均勻分發到每個active的節點，也就是說，某個資料庫節點成為master的機率是N分之一，N為active的節點數。

吸引機制能透過master節點上被訪問最多的buffer cache資源，來減少訊息傳遞和CPU的負載。吸引機制是在10gR1版本引入的，但是隻是針對datafile級別，如果某個datafile被某個instance經常訪問，所有屬於這個datafile的buffer都會remaster到這個節點上。從10gR2版本開始，吸引機制是基於object級別了。某個物件會在某個例項上特別的受歡迎，因此該節點上對應的global cache資源也會變成master。

吸引機制能透過減少程式碼路徑的長度和GCS的訊息傳遞，從而達到最佳化效能的效果。當一個block是在遠端節點是master，GCS資訊就要從請求者處傳送到master處。用來接收鎖分配和讀許可權。如果這個block remaster到了請求者的節點上，那麼訊息傳遞的過程就免了。其他類似的操作也會免了，如寫或關閉操作。

一旦吸引完成，請求者節點就基本上能“廉價”的affinity (b)locks，從而大量的減少程式碼路徑。

3、Undo affinity

undo的吸引和物件吸引類似，只不過它發生在undo block上，也就是說，所有的global cache資源的undo segment，都將master在某個例項上。

undo吸引發生在如下的情況下：

undo_management設定成auto時，發生在instance啟動的時候，在undo_tablespace裡面指定的undo segment，或者當undo_tablespace發生變化時候。

undo_management設定成manual是，發生在instance啟動時，在rollback_segments中指定的rollback_segments，或者執行“alter rollback segment…online”，致使rollback_segments變化。

當instance crash時，recovering instance會暫時master crash instance的undo block，當recover完成之後，所有的undo buffer會flush到disk上，用來最佳化remaster在crash instance再次啟動的時候。

當物件變成read-mostly的時候，開啟S lock就變成非常廉價的操作了，因為沒有訊息傳遞，並且沒有了分配和初始化LE（LOCK ELEMENT）、lock context、KJBL結構、KJBR結構和準備READING buffer。

read-mostly lock是非常簡單的在buffer header處標記KCBBHFRM，這和S lock的操作是等價的。read-mostly lock會很快被grant。

3DRM的大致機制

 GCS會追蹤每個節點、每個物件上的鎖請求和鎖型別，有3個程式執行DRM的功能：LCK0，LMD0和LMON。

一旦DRM請求開啟，它先會將請求插入到請求佇列中，接著，LMD0會為DRM請求檢查請求佇列，如果LMD0找到了一個請求，訊息將在各個節點間交換，然後set DRM為freeze狀態。  

當所有節點都成功的完成此操作後，LMON程式將發起和LMS程式一起進行remaster操作。

remaster的步驟和LMON程式的reconfiguration類似，remaster會在一個所謂的“視窗”完成，（“視窗”的大小原來由_lm_drm_window確定，在11g中由_lm_num_pt_bucket/_gc_latches決定。）這項技術由於只是凍結部分的資源，因此可用性得到了增強。

它的步驟包含以下幾個狀態：

QUIESCE - 這個狀態是發生在相關的block剛剛完成transfer的情況下，沒有新的OPENS和CONVERTS發生在remaster的資源上。

FREEZE - LMON程式等待所有節點都確認當前“視窗”已經被凍結。

CLEANUP - 老的master清理remote lock，並且刪除需要remaster的所有物件的resource。

REPLAY - 將本地的lock資訊傳送到新的master上。 

FIXWRITES - 重建新master節點上的資源的寫狀態。 

END - 解凍當前“視窗”，移動到下一個視窗。 

SYNC –發生在上述的步驟中。本地的節點等待其他節點完成他們之前的DRM操作。

4DRM的相關引數

1. _gc_policy_time (Oracle10g: _gc_affinity_time), default=10

表示檢查物件是否進行吸引或read mostly的時間間隔。

2. _gc_affinity_ratio (Oracle10g: _gc_affinity_limit), default=50

表示某節點上的物件訪問比其他節點多50倍（2015-11-30 15:40更新，注意是50倍，不是50次。），就認為是滿足吸引的條件。

3. _gc_policy_minimum (Oracle10g: _gc_affinity_minimum) default=600 in Oracle10g, 1500 in Oracle11g

表示在發生affinity之前，每分鐘每個CPU訪問檔案/物件的次數。當預設的超過每分鐘每個CPU 600次時，觸發吸引或read-mostly。 

4. _gc_undo_affinity and _gc_undo_affinity_locks, both default to TRUE

決定undo吸引是否進行。這個引數不建議改動。

5. _gc_transfer_ratio defaults to 2 (which means 50%)

如果block在記憶體間傳輸量少於從磁碟讀取的block的量的50%，那麼read mostly將會被允許進行。

6. _gc_affinity_locking and _gc_affinity_locks, both default to TRUE

決定物件吸引是否開啟。

7. _gc_read_mostly_locking, defaults to TRUE

決定read mostly特性是否啟用。

8. _lm_drm_max_requests, default=100

在一次DRM中，DRM請求能被處理的數量。

About Me

.......................................................................................................................................................................................................................................................................................................... ● 本文來自於微信公眾號轉載文章，若有侵權，請聯絡小麥苗及時刪除，非常感謝原創作者的無私奉獻 ● 本文在itpub（http://blog.itpub.net/26736162）、部落格園(http://www.cnblogs.com/lhrbest)和個人微信公眾號（xiaomaimiaolhr）上有同步更新 ● QQ群：230161599  微信群：私聊 ● 原文地址：http://mp.weixin.qq.com/s?__biz=MjM5MDAxOTk2MQ==&mid=2650272226&idx=1&sn=7a0ca3b29a65c5743f27e42ef3664dbb&chksm=be4869f4893fe0e2203a704b0c7905b0f98ed43ab15b775b741d30adf7f63f29c40610a2add5&mpshare=1&scene=23&srcid=1119oV9dQWGqpy6K2bl1EAYK#rd ● 小麥苗分享的其它資料：http://blog.itpub.net/26736162/viewspace-1624453/ ● 小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● QQ群： 230161599   微信群：私聊 ● 聯絡我請加QQ好友(642808185)，註明新增緣由 ● 文章內容來源於小麥苗整理的筆記，若有侵權或不當之處還請諒解！ ●【版權所有，文章允許轉載，但須以連結方式註明源地址，否則追究法律責任】 .......................................................................................................................................................................................................................................................................................................... 手機長按下圖識別二維碼或微信客戶端掃描下邊的二維碼來關注小麥苗的微信公眾號：xiaomaimiaolhr,免費學習最實用的資料庫技術。