during dynamic remastering (DRM) 的疑问
during dynamic remastering (DRM) 的疑问during dynamic remastering (DRM) 这个用途是RAC节点如果某个节点访问某个块次数超过几次，那么就把这个块的master给这个节点，意图是更有效的访问数据。
那么看起来，这个特性是用于负载均衡模式的（因为failolver模式 2个节点访问的表可能没有交集或者大部分表没有交集，那么不需要DRM），如果是用于负载均衡的话，1个块可能不断的被2个节点不断的访问，可能会出现比如这个时候节点A访问的多，DRM把块的master给节点A，下一个时间段节点B访问的多，那么DRM会将该块的master给节点B。
是不是这样连续的通过DRM转变块的master也不太高效。
Answer:
是否需要进行remaster，由几项数据决定：
1.) _gc_affinity_time = Time in minutes at which statistics will be evaluated (default = 10 mins)
2.) _gc_affinity_limit = # of times a node accesses a file/object (default = 50)
3.) _gc_affinity_minimum = minimum # of times per minute a file/object is accessed before affinity kicks in (default = 600 per minute per cpu )
满足了上面这些值，才会进行DRM，这样DRM会比较有意义。
不过现在还真是没有具体的数据说启用DRM和禁用DRM对性能的差距有多大。 1.oracle是依据什么方法划分数据块的master节点，通过什么视图查询确认？
Answer：
10gr2之后的Oracle是根据object_id的hash value 来划分的master节点
2.划分master节点的方法在数据库每一次重启是否都是相同的？
Answer:
如果hash value 不变，每次重启资源的master节点也不会改变；
3.如何手工触发数据库对象的master节点发生变化，通过视图查询确认？
Answer：
remaster的过程由于是动态获取的read affinity的信息出发自动执行的，目前Oracle没有提供外部的接口来执行remaster的操作；
唯一可以对某一个对象进行remaster操作的方法您需要用oradebug的工具来做，您可以通过视图 GV$GCSPFMASTER_INFO 来获取remaster的信息：
我这里给您提供一个test case 如下：
SQL> oradebug lkdebug -m pkey 22382
Statement processed.
SQL> select * from GV$GCSPFMASTER_INFO where data_object_id =22382;
INST_ID FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- ----------- -------------- --------------- ------------
1 0 22382 Affinity 0 32767 1
2 0 22382 Affinity 0 32767 1
....
SQL> select * from GV$GCSPFMASTER_INFO where data_object_id =22382;
INST_ID FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- ----------- -------------- --------------- ------------
1 0 22382 Affinity 1 0 2
2 0 22382 Affinity 1 0 2
SQL>
注意：32767 并非表示之前的节点是32767， 这个值表示 affinity/read-mostly 从来没有对这个对象进行计算过，也没有发生过DRM的操作；
SQL> oradebug lkdebug -m pkey 22382
这个操作只是在您的非master的节点上才能生效；
另外，我没有找到官方的文档或者note具体讲这个算法，但是我们可以看到每次集群发生reconfiguration的过程中，都会有这样的信息报告在alert日志中：
Reconfiguration started (old inc 70, new inc 72)
List of instances:
1 2 (myinst: 2)
Global Resource Directory frozen
Communication channels reestablished
Sat Jul 14 14:17:04 2012
* domain 0 valid = 1 according to instance 1
Master broadcasted resource hash value bitmaps <<<<<=========我们可以看到GRD的重组的过程中当前的GRD会boradcast 资源的hash value bitmaps 来进行GRD的重组；
SQL> create table drm_test as select * from all_tables;
Table created.
SQL> select object_id from dba_objects where object_name='DRM_TEST';
OBJECT_ID
----------
22847
SQL>
检查初始状态的数据块分布情况：
on node1 :
SQL> select count(*) from X$KJBR where KJBRPKEY=22847;
COUNT(*)
----------
4
SQL>
SQL> select * from X$KJBR where KJBRPKEY=22847;
ADDR INDX INST_ID KJBRRESP KJBRGRANT KJBRNCVL KJBRROLE KJBRNAME KJBRMASTER KJBRGRAN KJBRCVTQ KJBRWRIT KJBRSID KJBRRDOMID KJBRPKEY
-------- ---------- ---------- -------- --------- --------- ---------- ------------------------------ ---------- -------- -------- -------- ---------- ---------- ----------
00A8B6F8 297 1 255C1268 KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 0 213F8320 00 00 0 0 22847
00A8B6F8 683 1 255907AC KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 0 217F58F0 00 00 0 0 22847
00A8B6F8 1075 1 255C0488 KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 0 223E8150 00 00 0 0 22847
00A8B6F8 1450 1 2558BC84 KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 0 20BF0EB8 00 00 0 0 22847
SQL>
on node2:
SQL> select count(*) from X$KJBR where KJBRPKEY=22847;
COUNT(*)
----------
3
SQL>
SQL> set linesize 500
SQL> select * from X$KJBR where KJBRPKEY=22847;
ADDR INDX INST_ID KJBRRESP KJBRGRANT KJBRNCVL KJBRROLE KJBRNAME KJBRMASTER KJBRGRAN KJBRCVTQ KJBRWRIT KJBRSID KJBRRDOMID KJBRPKEY
-------- ---------- ---------- -------- --------- --------- ---------- ------------------------------ ---------- -------- -------- -------- ---------- ---------- ----------
006EF730 136 2 2553BF54 KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 1 25582B3C 00 00 0 0 22847
006EF730 469 2 25516AB4 KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 1 2556E8BC 00 00 0 0 22847
006EF730 951 2 255232BC KJUSEREX KJUSERNL 0 ,[ext 0x0,0x 1 255754DC 00 00 0 0 22847
SQL>
通过以上信息，我们可以看到GRD的构建是按照数据块构建的
我们出发一次DRM
SQL> oradebug setmypid
Statement processed.
SQL> oradebug lkdebug -m pkey 22847
Statement processed.
SQL> select * from GV$GCSPFMASTER_INFO where data_object_id =22847;
INST_ID FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- ----------- -------------- --------------- ------------
2 0 22847 Affinity 1 32767 1
1 0 22847 Affinity 1 32767 1
SQL>
我们看到这个object已经做了DRM ，现在的master节点为2
查询KJBR的视图
SQL> select count(*) from X$KJBR where KJBRPKEY=22847;
COUNT(*)
----------
0
《《《《《===============目前正在找这个表中数据在DRM后消失的原因
根据我之前提供给您的test case ，数据块最开始的分布，确实是如您所说；
是细化到block 进行分配的master；
只有在DRM的过程中才会按照以pkey（object_id）来作为最小单位；
我这里测试只验证了我们电话里聊的内容，但是我也碰见了以下情况：
重启：X$KJBR这个表里两个实例中都有数据；
但是
一旦手工调用DRM后：X$KJBR 数据就从两个实例都消失了；
由于X$的表，没有官方的解释，我这里暂时也没办法帮您解释这个现象；这个问题也超出了我们这个SR的范畴，而且我这周都在培训，暂时没办法继续测试，如果您还有兴趣，您可以提交新的SR来分析（临近中国的假期，建议您提交英文的SR），或者等我节后帮您继续测试；
页:
[1]