DRM 分析及案例講解

DRM 分析及案例講解

什麼是DRM

RAC是每個執行個體都有其自己的SGA和buffer

cache。RAC為了確定這些塊發生時的最大化性能,確定資料完整。每個緩沖區副本也稱為緩存資源有一個主要的将做為一個主要的叢集節點。在資料庫版本10g(10.1.0.2)一個主要的緩存資源負責掌管一個執行個體,re-mastering或改變主節點隻會發生在重新配置,會自動在兩個正常操作執行個體啟動或執行個體關閉，異常節點叢集管理器将對其進行逐出。是以,如果節點B這個時候作為一個主緩存的資源,這個資源仍将掌握在節點B直到重新配置。10g中引入了一個新概念,通過DRM資源進行remaster。與DRM資源可以在另一個節點上重新優化,從節點B節點如果發現更頻繁地通路緩存資源從節點a重新配置不再是資源重新優化的唯一原因。

到10gR2是基于相關對象的，下面是DRM的跟蹤trace檔案，在Oracle日志中的LMD程序資訊裡面。

Sample LMD trace file during a DRM operation

Begin DRM(202) - transfer pkey 4294951314 to0 oscan 1.1 

*** 2006-08-01 17:34:54.645 

Begin DRM(202) - transfer pkey 4294951315 to 0 oscan 1.1 

*** 2006-08-01 17:34:54.646 

Begin DRM(202) - transfer pkey 4294951316 to 0 oscan 1.1 

Begin DRM(202) - transfer pkey 4294951317 to 0 oscan 1.1

remastering的發生:

    Remastering問題發生時會影響性能。以下AWR報告顯示了DRM重配置問題導緻的執行個體當機。同樣類型的當機在其它的所有節點上也都可以看見。gc

buffer busy等待隻是DRM當機的副作用（不是總有，但是在這個case是這樣）。

   在同一時刻，DRM大量發生，導緻了重複的DRM當機、執行個體重配置，進而引發嚴重的性能問題。

可以看到，TOP 5中，有3個是latch相關的等待，而另外2個則是跟RAC相關的等待。

如果再檢視更細的等待資料，可以發現其他問題：

    從上面的資料還可以看到，除了TOP 5等待，還有”gcs drm freeze in enter servermode“以及”gc remaster”這2種比較少見的等待事件，從其名稱來看，明顯與DRM有關。那麼這2種等待事件與TOP5的事件有沒有什麼關聯？。MOS文檔”Bug

6960699- “latch: cache buffers chains” contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/OERI[kjbldrmrpst:!master] [ID 6960699.8]”提及，DRM的确可能會引起大量的”latch: cache buffers chains”、”latch:

objectqueue header operation”等待，雖然文檔沒有提及，但不排除會引起”latch: cachebuffers lru chain“這樣的等待。

    為了進一步證明性能問題與DRM相關，使用tail -f指令監控LMD背景程序的trace檔案。在trace檔案中顯示開始進行DRM時，查詢v$session視圖，發現大量的

“latch: cache buffers chains” 、”latch:object queue header operation”等待事件，同時有”gcs drm freezein enter server mode“和”gc remaster”等待事件，同時系統負載升高，前台反映性能下降。而在DRM完成之後，這些等待消失，系統性能恢複到正常。

A small test case 

   我們來看一個測試，觀察一下DRM的産生。使用了索引讀路徑的查詢從一個大索引中讀取了幾乎所有資料塊。

我們的測試表明，該索引上發生了大量的BL鎖請求，之後對象被remastering。

Undo and affinity

   復原段的Mastering和其它段不同。對于非復原段而言，一個段上的所有資料塊通過雜湊演算法被分散在各個執行個體間。隻有在經過大量的BL鎖請求以後，段才會被mastering。但是對于復原段而言，激活了一個復原段的執行個體立刻成為該段的屬主。這是合乎情理的，因為在大多數情況下復原段将會被打開這個segment的執行個體使用。初始化參數_gc_undo_affinity控制這種動态undo

remastering動作是否發生。

   因為復原段沒有真正的object_id，是以使用4294950912作為虛拟object_ids的基準值。比如說，復原段1（usn=1）的object_id是4294950913，復原段2（usn=2）的object_id就是4294950914，依次類推（4294950912

= power(2,32) – power (2,14)= xFFFFC000）。

  我沒有成功試驗出觸發下一次復原段remastering。我建立了一個活動事務在一個節點上産生了200K復原資料塊，然後另外一個節點在讀這個表，我觀察到在復原資料塊上有大量等待。但是我沒有發現這個復原段上有任何remastering事件。無法确認為什麼沒有産生，也許是復原段remastering的條件有所不同吧。

譯者注：復原段的remastering是不會因為另外一個節點對于復原段有大量讀取而發生的，隻有在某個執行個體失效，然後負責進行執行個體恢複的另外那個執行個體會暫時的成為這些復原段的master，這是為了進行執行個體恢複的需要，在恢複完畢以後所有的undo

buffers都會被flush到磁盤上。

PS：我能夠使用後面将描述的lkdebug指令手動remaster復原段，是以oracle也應該可以自動remaster復原段，隻是可能還有一個其它條件也必須滿足。

  我不是在勸你們應該去修改這些隐含參數。隻是要去了解這些參數，如果你們碰到諸如’gc remaster’, ‘gcs freeze for instancereconfiguration’這樣的等待事件，那麼應該知道是不是因為預設值太低了。跟技術支援溝通嘗試是否能夠調整。

Manual remastering

你可以使用oradebug指令來手動remaster一個對象：

這會将一個對象remaster請求放入隊列。LMD0和LMON程序會完成這個請求。

目前屬主是從0開始計數的。

Summary

總結一下，remarstering是個很棒的功能。不過遺憾的是，我們有時候會成為它負面效果的受害者。是以，如果你碰到remastering引起的問題，不要直接就禁用它，而是應該去看看能否調優那些參數進而控制remastering事件。如果你仍然想完全禁用DRM，那麼我建議設定_gc_affinity_limit和_gc_affinity_minimum參數到一個較高值，比如說1千萬。将參數_gc_affinity_time設定為0也可以完全禁用DRM，但是這也意味着再也無法手工remaster對象了。另外，Arup也提到如果DRM被禁用那麼x$object_affinity_statistics表也不會再被維護。

Update 1:

從11g開始，affinity管理更名為policy管理（政策管理）。比如說，x$object_affinity_statistics表改名為x$object_policy_statistics，與之相似的，初始化參數也發生了改變：參數_gc_affinity_limit改名為_gc_policy_limit；參數_gc_affinity_time改名為_gc_policy_time；出現了一個新的視圖v$policy_history，其中所有policy_event = ‘initiate_affinity’的記錄都是與DRM事件相關的。

本blog的其它部分仍然沒問題，除了預設的_gc_policy_limit參數值降低為1500，這意味着，在理論上，11g可能會産生更多的DRM事件。

與DRM有關的一些參數

10g：

看起來，隻需要關閉DRM就能避免這個問題。怎麼樣來關閉/禁止DRM呢？很多MOS文檔提到的方法是設定2個隐含參數：

不幸的是，這2個參數是靜态參數，也就是說必須要重新開機執行個體才能生效。

實際上可以設定另外2個動态的隐含參數，來達到這個目的。按下面的值設定這2個參數之後，不能完全算是禁止/關閉了DRM，而是從”事實上“關閉了DRM。

甚至可以将以上2個參數值設定得更大。這2個參數是立即生效的，在所有的節點上設定這2個參數之後，系統不再進行DRM，經常一段時間的觀察，本文描述的性能問題也不再出現。

11g

參考：

<a target="_blank" href="http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_1/">http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_1/</a>

<a target="_blank" href="http://www.dbform.com/html/tag/drm">http://www.dbform.com/html/tag/drm</a>

<a target="_blank" href="http://wenku.baidu.com/link?url=DykRyVGrvpLkfHUMrgoUOKghYXLAzh3YRSu1AHksMwdSmL5b8XtEcEocQcC7ziRrzd6OF54w9w4TBHuHo486MsXwJFhBrtKe5r3jdtA8joS">http://wenku.baidu.com/link?url=DykRyVGrvpLkfHUMrgoUOKghYXLAzh3YRSu1AHksMwdSmL5b8XtEcEocQcC7ziRrzd6OF54w9w4TBHuHo486MsXwJFhBrtKe5r3jdtA8joS</a>

<a target="_blank" href="http://www.laoxiong.net/problem-caused-by-drm.html">http://www.laoxiong.net/problem-caused-by-drm.html</a>