Oracle 10g RAC中的DRM問題及關閉

在RAC環(huán)境中，Oracle使用GRD（Global Resource Service）來記錄各個RAC節(jié)點的資源信息，具體通過GCS（Global Cache Service）和GES（Global Enqueue Service）這兩個服務進行管理。

由于在RAC中每個節(jié)點都有自己的SGA和buffer cache，為了保證Cache資源的一致性和提高性能，GCS和GES會指定RAC中的一個instance來管理Cache，這個節(jié)點這時就是Resource Master。
-
 

在10g以前，Cache資源是不能在各個節(jié)點間移動的，除非重啟或者某節(jié)點因為其他異常被RAC驅逐等情況。而10g的DRM就解決了這個問題，它可以保證cache能夠被remaster到頻繁訪問這部分數(shù)據(jù)的節(jié)點上，從而提高RAC的性能。DRM的全稱是Dynamic Resource Mastering，metalink上的Doc ID:  390483.1文檔詳細介紹了DRM的信息。

從理論上講，利用此項技術，非master節(jié)點對所需資源有頻繁訪問需求時，www.linuxidc.com可以提升為master節(jié)點，從而減少大量后續(xù)的跨節(jié)點資源訪問需求。

但是，首先從根本上說，一個好的RAC應用設計，本就應該極盡所能的取避免同一資源的多節(jié)點訪問，如果不存在同一資源的多節(jié)點訪問，則DRM所要解決的問題，就根本不存在。其次，DRM本身是需要消耗資源的，并且存在諸多bug，對于一個設計較差的系統(tǒng)而言，頻繁的DRM，也會引發(fā)Libary cache lock而導致實例掛住。

更嚴重的，在10.2.0.3系統(tǒng)上，曾經(jīng)遇到一個case，電信行業(yè)的巨型數(shù)據(jù)庫，rac的2號節(jié)點由于批量處理作業(yè)在非業(yè)務時間段，首先cache了一張40G的表，而到了業(yè)務時間段后，rac的1號節(jié)點的OLTP業(yè)務需要頻繁訪問該表，此時，故障發(fā)生了，由于DRM的介入，2號節(jié)點開始將內(nèi)存內(nèi)的40Gcache數(shù)據(jù)向1號節(jié)點傳輸，心跳網(wǎng)段千兆帶寬被耗盡，RAC陷入僵死階段，足足維持了40分鐘。

事后檢查網(wǎng)絡流量圖，該時段內(nèi)，私有網(wǎng)絡流量持續(xù)保持在90M/s的峰值水平。

根據(jù)metalink確認，該問題確實由DRM機制引起，最終解決方案，使用隱含參數(shù)，將DRM特性屏蔽：

_gc_affinity_time=0

_gc_undo_affinity=FALSE

因此，從根本上來說，drm的出現(xiàn)，只是在理論上的一種緩解，而并不能在實際的大型應用中發(fā)揮其作用。就類似于Oracle自己針對RAC推出的自動負載平衡一樣，只是一種看起來很美的東西，如果真的有人用了，呵呵，那就只能等死吧�；蛟S壓力極小的數(shù)據(jù)庫無所謂，但我沒遇到過，話又說回來，壓力極小，又何必上RAC呢。

為了技術而技術，不是我們的最終目的，科技以人為本，技術也一樣，人，才是最重要的決定因素。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]