Oracle 10g RAC中的DRM問題及關(guān)閉

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

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

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

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

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

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

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

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

_gc_affinity_time=0

_gc_undo_affinity=FALSE

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

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

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