oracle gc remaster,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呢。