during dynamic remastering (DRM) 的疑问

ALLSTARS_ORACLE

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对性能的差距有多大。

ALLSTARS_ORACLE

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 [0x9c5b0][0x5],[BL][ext 0x0,0x 0 213F8320 00 00 0 0 22847
00A8B6F8 683 1 255907AC KJUSEREX KJUSERNL 0 [0x9c5a0][0x5],[BL][ext 0x0,0x 0 217F58F0 00 00 0 0 22847
00A8B6F8 1075 1 255C0488 KJUSEREX KJUSERNL 0 [0x9c590][0x5],[BL][ext 0x0,0x 0 223E8150 00 00 0 0 22847
00A8B6F8 1450 1 2558BC84 KJUSEREX KJUSERNL 0 [0x9c580][0x5],[BL][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 [0x916f0][0x5],[BL][ext 0x0,0x 1 25582B3C 00 00 0 0 22847
006EF730 469 2 25516AB4 KJUSEREX KJUSERNL 0 [0x916f2][0x5],[BL][ext 0x0,0x 1 2556E8BC 00 00 0 0 22847
006EF730 951 2 255232BC KJUSEREX KJUSERNL 0 [0x916f1][0x5],[BL][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），或者等我节后帮您继续测试；