在rac環境中，oracle使用grd（global resource service）來記錄各個rac節點的資源資訊，具體通過gcs（global cache service）和ges（global enqueue service）這兩個服務進行管理。
由於在rac中每個節點都有自己的sga和buffer cache，為了保證cache資源的一致性和提高效能，gcs和ges會指定rac中的乙個instance來管理cache，這個節點這時就是resource master。
在10g以前，cache資源是不能在各個節點間移動的，除非重啟或者某節點因為其他異常被rac驅逐等情況。而10g的drm就解決了這個問題，它可以保證cache能夠被remaster到頻繁訪問這部分資料的節點上，從而提高rac的效能。drm的全稱是dynamic resource mastering，metalink上的doc id: 390483.1文件詳細介紹了drm的資訊。
從理論上講，利用此項技術，非master節點對所需資源有頻繁訪問需求時，可以提公升為master節點，從而減少大量後續的跨節點資源訪問需求。
但是，首先從根本上說，乙個好的rac應用設計，本就應該極盡所能的取避免同一資源的多節點訪問，如果不存在同一資源的多節點訪問，則drm所要解決的問題，就根本不存在。其次，drm本身是需要消耗資源的，並且存在諸多bug，對於乙個設計較差的系統而言，頻繁的drm，也會引發libary cache lock而導致例項掛住。
更嚴重的，在10.2.0.3系統上，曾經遇到乙個case，電信行業的巨型資料庫，rac的2號節點由於批量處理作業在非業務時間段，首先cache了一張40g的表，而到了業務時間段後，rac的1號節點的oltp業務需要頻繁訪問該錶，此時，故障發生了，由於drm的介入，2號節點開始將記憶體內的40gcache資料向1號節點傳輸，心跳網段千兆頻寬被耗盡，rac陷入僵死階段，足足維持了40分鐘。
事後檢查網路流量圖，該時段內，私有網路流量持續保持在90m/s的峰值水平。
根據metalink確認，該問題確實由drm機制引起，最終解決方案，使用隱含引數，將drm特性遮蔽：
_gc_affinity_time=0
_gc_undo_affinity=false
因此，從根本上來說，drm的出現，只是在理論上的一種緩解，而並不能在實際的大型應用中發揮其作用。就類似於oracle自己針對rac推出的自動負載平衡一樣，只是一種看起來很美的東西，如果真的有人用了，呵呵，那就只能等死吧。或許壓力極小的資料庫無所謂，但我沒遇到過，話又說回來，壓力極小，又何必上rac呢。
為了技術而技術，不是我們的最終目的，科技以人為本，技術也一樣，人，才是最重要的決定因素。
oracle 10g rac關機步驟
oracle 10g rac關機步驟？oraclerac的啟動和關閉 情況1 停止資料庫及作業系統，伺服器，需要關閉db 所有例項 os及server a.首先停止oracle10g環境 lsnrctl stop 每個節點上停止監聽，也可以用srvctl來操作 emctl stop dbconsol...
Oracle10g RAC 關閉及啟動步驟
情況1 保養資料庫及作業系統，伺服器，需要關閉db 所有例項 os及server 注 srvctl 也可以用來關閉某個例項 srvctl stop instance d orcl i orcl2 srvctl 開啟關閉 srvctl stop listener n orcl2 srvctl star...
ORACLE10GRAC節點自動重啟故障處理
將資料庫集群公升級到10.2.0.5之後，雙節點伺服器不斷重啟，查詢oracle oprocd程序日誌，資訊如下 jul 03 08 16 34.702 inf monitoring started with timeout 1000 margin 500 skewtimeout 125 jul 0...