Oracle DRM 和 read-mostly locking 說明 (轉)

瞭解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

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

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。

DRM的大致機制

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操作。

DRM的相關參數

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請求能被處理的數量。

Ref:

DRM和read-mostly locking