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环境中,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节点对所需资源有频繁访问需求时,www.linuxidc.com可以提升为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呢。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29446986/viewspace-1294958/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29446986/viewspace-1294958/