ORACLE DRM REMASTER AN OBJECT

 
We can only remaster an object when DRM is enabled . 


e.g on 11.2 


_gc_policy_time can't be 0 


Here is a test case : 




Test Env: 11.2.0.3 RAC 


Test Process: 


1. Disable DRM: 
1)Set below parameter: 
SQL>alter system set "_gc_policy_time"=0 scope=spfile; 


2) Must shutdown of all the instances. **** 


3) Startup all of the instances and verify the parameter has been changed. 
SQL>select ksppinm as "hidden parameter", ksppstvl as "value" 
from x$ksppi join x$ksppcv using (indx) 
where ksppinm like '\_%' escape '\' and ksppinm like '_gc_policy_time' 
order by ksppinm; 


2. Manually remaster: 
SQL> select data_object_id from dba_objects where object_name='EMP' and owner='SCOTT'; 
DATA_OBJECT_ID 
-------------- 
75315 


SQL> select * from GV$GCSPFMASTER_INFO where data_object_id = 75315; 


no rows selected 


SQL> oradebug setmypid 
Statement processed. 


SQL> oradebug lkdebug -m pkey 75315 <<<<<==================Remaster object 75315 
Statement processed. 


SQL> select * from GV$GCSPFMASTER_INFO where data_object_id = 75315; <<<<<==================Failed 


no rows selected 


3. Unable to remaster the object by lkdebug. 


4. From the generated trace file: 


*** 2013-05-29 09:25:18.976 
Processing Oradebug command 'lkdebug -f 75315' 
***************************************************************** 
GLOBAL ENQUEUE SERVICE DEBUG INFORMATION 
---------------------------------------- 
There is no affinity on pkey 75315 


*** 2013-05-29 09:25:38.274 
Processing Oradebug command 'lkdebug -m pkey 75315' 
***************************************************************** 
GLOBAL ENQUEUE SERVICE DEBUG INFORMATION 
---------------------------------------- 
* lkdebug: cannot handle affinity request for object # 75315, affinity is turned off! 


SQL> alter system set "_gc_policy_time"=10 scope=spfile; <<<<<=================Enable DRM 
System altered. 


2. Restart all instances. 


3. Run on instance1: 
SQL> oradebug setmypid 
Statement processed. 


SQL> oradebug lkdebug -m pkey 75315 <<<<<==================Remaster object 75315 again 
Statement processed. 


SQL> select * from GV$GCSPFMASTER_INFO where data_object_id = 75315; 


INST_ID FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER <<<<<==================Remastered 
---------- ---------- -------------- ----------- -------------- --------------- 
REMASTER_CNT 
------------ 
2 0 75315 Affinity 0 1 2 


1 0 75315 Affinity 0 1 2 

在RAC環境中，使用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呢。