DRM分析及案例讲解 - 数据库编程

+4294950912;

FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- --------------- ------------
0 4294951343 0 32767 1

Oradebug lkdebug –m pkey 4294951343

* kjdrchkdrm: found an RM request in the request queue

Transfer pkey 4294951343 to node 1

*** 2010-03-24 12:47:29.011

Begin DRM(520) - transfer pkey 4294951343 to 1 oscan 0.1

ftd received from node 0 (4/0.31.0)

all ftds received

select * from v$gcspfmaster_info where object_id=431+4294950912;

SQL> /

FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- --------------- ------------

0 4294951343 1 0 2

我不是在劝你们应该去修改这些隐含参数。只是要去理解这些参数，如果你们碰到诸如’gc remaster’, ‘gcs freeze for instancereconfiguration’这样的等待事件，那么应该知道是不是因为默认值太低了。跟技术支持沟通尝试是否能够调整。

Manual remastering
你可以使用oradebug命令来手动remaster一个对象：

oradebug lkdebug -m pkey

这会将一个对象remaster请求放入队列。LMD0和LMON进程会完成这个请求。

当前属主是从0开始计数的。

*** 2010-01-08 23:25:54.948
* received DRM start msg from 1 (cnt 1, last 1, rmno 191)
Rcvd DRM(191) Transfer pkey 6984154 from 0 to 1 oscan 0.0
ftd received from node 1 (8/0.30.0)
ftd received from node 0 (8/0.30.0)
ftd received from node 3 (8/0.30.0)

select * from v$gcspfmaster_info whereobject_id=6984154;

SQL> / 

FILE_ID OBJECT_ID CURRENT_MASTERPREVIOUS_MASTER REMASTER_CNT 
---------- ---------- ----------------------------- ------------ 
0 6984154 1 0 2 

SQL> oradebug lkdebug -m pkey 6984154 

Statement processed. 

SQL> select * from v$gcspfmaster_info where object_id=6984154; 

FILE_ID OBJECT_ID CURRENT_MASTERPREVIOUS_MASTER REMASTER_CNT 
---------- ---------- ----------------------------- ------------ 
0 6984154 2 1 3

Summary
总结一下，remarstering是个很棒的功能。不过遗憾的是，我们有时候会成为它负面效果的受害者。所以，如果你碰到remastering引起的问题，不要直接就禁用它，而是应该去看看能否调优那些参数从而控制remastering事件。如果你仍然想完全禁用DRM，那么我建议设置_gc_affinity_limit和_gc_affinity_minimum参数到一个较高值，比如说1千万。将参数_gc_affinity_time设置为0也可以完全禁用DRM，但是这也意味着再也无法手工remaster对象了。另外，Arup也提到如果DRM被禁用那么x$object_affinity_statistics表也不会再被维护。

Update 1:
从11g开始，affinity管理更名为policy管理（策略管理）。比如说，x$object_affinity_statistics表改名为x$object_policy_statistics，与之相似的，初始化参数也发生了改变：参数_gc_affinity_limit改名为_gc_policy_limit；参数_gc_affinity_time改名为_gc_policy_time；出现了一个新的视图v$policy_history，其中所有policy_event = ‘initiate_affinity’的记录都是与DRM事件相关的。
本blog的其它部分仍然没问题，除了默认的_gc_policy_limit参数值降低为1500，这意味着，在理论上，11g可能会产生更多的DRM事件。

select * from  v$policy_history

   INST_ID POLICY_EVENT         DATA_OBJECT_ID TARGET_INSTANCE_NUMBER  EVENT_DATE

---------- -------------------- -------------- ----------------------  --------------------
          2 glru_on                           0                      1  10/15/2010 10:58:28
         2 glru_on                           0                      1  10/15/2010 11:21:32
         2 initiate_affinity             74809                      1  10/15/2010 13:27:44

与DRM有关的一些参数

10g：

看起来，只需要关闭DRM就能避免这个问题。怎么样来关闭/禁止DRM呢？很多MOS文档提到的方法是设置2个隐含参数：

_gc_affinity_time=0

_gc_undo_affinity=FALSE

不幸的是，这2个参数是静态参数，也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数，来达到这个目的。按下面的值设置这2个参数之后，不能完全算是禁止/关闭了DRM，而是从”事实上“关闭了DRM。

甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的，在所有的节点上设置这2个参数之后，系统不再进行DRM，经常一段时间的观察，本文描述的性能问题也不再出现。

11g

_gc_policy_limit=1500

_gc_policy_time=0

参考：

http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_sea

DRM分析及案例讲解(五)