ORACLE RAC的DRM (動態資源管理）

在RAC 11.2.0.4生產環境中，每天某個時間，MQ發生大量交易堵塞，從原先的每分鐘2千多筆，掉到1千多筆，從資料庫後臺監控來看，叢集GC出現大量堵塞。懷疑RAC發生DRM。

從官方文件中，理解DRM機制，RAC每個例項都有自己的SGA和buffer cache，每個block都有都有一個例項主控，該例項負責跟蹤block變化情況。例如當一個節點發生down機，將發生dynamic resource  reconfiguration (動態資源重新配置）。除此之外還有一種情況，主控節點buffer cache resource 大量被訪問，為了確定是否需要動態remaster，GCS基於每個例項和每個物件跟蹤GCS請求，當發現同一個物件block在一個節點被頻繁訪問，GCS將動態把所有例項上該物件資源遷移到訪問最頻繁的節點之中，LMON，LMD和LMS將負責動態remaster。

 分析生產交易，有一張流水錶高頻度插入資料，且監控中可以看到兩個節點直接都有在執行。

  oracle官方提供了一個診斷指令碼DRMDIAG.SQL，通過v$active_session_history可以看到在效能下降的那個時刻發生drm free。
         ---求閾值
           column threshold_in_ms new_value threshold format 999999999.999
           select decode(min(threshold_in_ms),null,0,min(threshold_in_ms)) threshold_in_ms
           from (select inst_id, to_char(sample_time,'Mondd_hh24mi') minute,
           sum(time_waited)/1000 threshold_in_ms
            from gv$active_session_history
            where event like '%drm freeze%'
           group by inst_id,to_char(sample_time,'Mondd_hh24mi')
           order by 3 desc)
           where rownum <= 10;
        --檢視發生DRM時間，等待時間和次數
           column event format a30 tru
           column program format a35 tru
           column total_wait_time format 999999999999.999
           column avg_time_waited format 999999999999.999
           select to_char(sample_time,'Mondd_hh24mi') minute, inst_id, event,
           sum(time_waited)/1000 TOTAL_WAIT_TIME , count(*) WAITS,
           avg(time_waited)/1000 AVG_TIME_WAITED
           from gv$active_session_history
            where event like '%drm freeze%'
            group by to_char(sample_time,'Mondd_hh24mi'), inst_id, event
           having sum(time_waited)/1000 > &&threshold
           order by 1,2;

通過內部引數關閉DRM，需要重新啟動資料庫
alter system set " _gc_policy_time"=0 scope=spfile sid='*';
alter system set "_gc_undo_affinity"=false scope=spfile sid='*';

總結：在交易型生產系統中，應用伺服器通過SCAN IP連線資料庫，如果對某個流水錶高頻度進行操作，建議關閉DRM

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/354732/viewspace-2146330/，如需轉載，請註明出處，否則將追究法律責任。