drm android 工作原理,DRM原理及案例探讨

DRM原理及案例探讨

Master节点

•主要作用为调度、协调、管理或者是走流程。主要分为以下几大类：

ØClusterware级别。查看方法如下：

cd $GRID_HOME/log/hostname/cssd

grep -i "master node" ocssd.log | tail -1

Ø全局资源级别。查看方法如下：

查询视图V$GES_RESOURCE.MASTER_NODE

ØDatabase block。查看方法如下：

查询视图V$GCSPFMASTER_INFO.CURRENT_MASTER

Buffer lock

•进程访问buffer前，都需要申请持有buffer lock。Lock mode的兼容性如下：NSX

NYesYesYes

SYesYesNo

XYesNoNo

场景：节点之间请求修改数据块

简单流程如下：

1)节点B(申请者)向节点D(主节点)发出请求，要求以X模式锁定块1008。

2) 节点D (主节点)发现节点C(持有者)已经以S模式获得了对应的锁，而且S锁于X锁之间是不兼容的，所以，需要锁的转换，节点D要求节点C将对应的锁级别降低为N，所得属性为NL0。

3) 节点B将自己的锁降级，并且将本地的块1008 标识为CR。之后，节点B将块1008 修改为块1009，同时将通知节点D锁的属性为XL0。

•主节点在持有者节点和申请者节点之间不停地调度、传递消息

•如果锁的角色是全局(数据块在其他远程节点buffer里被修改过)，那么我们要做的事情更多，也意味着访问的代码深度也越深

DRM(Dynamic Resource management)

•指定时间内(默认10分钟，受_gc_policy_time 控制)，对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式，来决定数据库对象对应的block应该被mastering 到哪一个实例

•指定时间内，如果某一个实例访问某个数据库对象次数高于其他实例一定倍数(默认50倍，受_gc_affinity_ratio控制)，则oracle 会把这个对象所有的buffer的master信息，转移到对应实例

注意：

•DRM的过程是渐进式的。

•请不要修改以上参数的值，除非您很清楚自己在做什么。

•Remaster数据块的过程如下(可能不完善)：

(1) Oracle停止所有在需要进行remastering的buffer上的操作

(2)LMD0进程读取等待remaster数据块队列

(3)GRD(Global Resource Directory)内存结构可能会frozen

(4)LMON进程通知所有实例协调LMS进程进行reconfigration

(5)在旧的master实例清除对应buffer的master信息

(6)将master信息传递给新的master实例

(7)在新的master实例构建资源的最新状态

(8)结束，并释放所有之前所有步骤占用的资源

再次强调：

DRM进行remaster时，转移的并不是块本身，而是master节点。通过master节点可以知道当前哪个节点在访问这个块，访问时的lock mode是什么。

•数据块的Master节点信息保存在内存结构中，实例重启也就意味着失效。DRM重构风暴？没听说过。

•在reconfiguration或者繁忙的系统中，GRD可能会处于frozen状态(Bug 14641937/14618938)，所以remaster时系统可能会短时间hang(Oracle一直在改进该算法，可是。。。)

DRM的应用场景

•如果是应用分离，那么最好使用DRM特性。

•如果是负载均衡，那么建议关闭DRM特性。

•DRM相关的bug让人防不胜防(数据库宕机，节点驱逐， 数据库挂起， ORA-00600)，其bug列表如下：

•关闭DRM特性(请谨慎评估，三思而后行)

ØOracle 10g中，设置如下参数：

_gc_affinity_time=0

_gc_undo_affinity=FALSE

或者(实时生效，不需要重启实例)

_gc_affinity_limit=10000000

_gc_affinity_minimum=10000000

ØOracle 11g中，设置如下参数：

_gc_policy_time=0

也可关闭DRM的局部特性(这个很重要)：

_gc_read_mostly_locking=false

_gc_bypass_readers=false

进一步解析DRM

•跟BUFFER CACHE的访问机制类似，ORACLE会使用HASH 算法来决定每个BLOCK的MASTER是哪个节点(可以查询内部视图x$kjbl、x$le)

•默认情况下，HASH产生的BUCKET是 128(由隐含参数_lm_contiguous_res_count 决定)

案例：DRM引起的select hang

•案例背景：

ØAIX主机，数据库版本为10.2.0.4，2节点RAC

Ø业务主要在1号节点运行，2号节点处于空闲状态

Ø1号节点在create table之后马上进行全表select，不定时出现hang

ØHang的时间段为凌晨，主机资源和数据库资源非常空闲

•解决思路：

Ø同时对hang进程进行10046 level 12跟踪。跟踪结果显示如下：WAIT #3: nam='i/o slave wait' ela= 12313 msg ptr=2 p2=56 p3=2147483647 obj#=98754

WAIT #3: nam='db file scattered read' ela= 14260 file#=4 block#=142603 blocks=126 obj#=98754

WAIT #3: nam='gc cr multi block request'ela= 2859 file#=4 block#=142803 class#=1 obj#=98754

WAIT #3: nam='gc cr multi block request'ela= 6321 file#=4 block#=142820 class#=1 obj#=98754

WAIT #3: nam='gc cr multi block request'ela= 2262 file#=4 block#=142841 class#=1 obj#=98754

WAIT #3: nam='gc cr multi block request'ela= 6427 file#=4 block#=142847 class#=1 obj#=98754

WAIT #3: nam='i/o slave wait' ela= 11540 msg ptr=2 p2=56 p3=2147483647 obj#=98754

WAIT #3: nam='db file scattered read' ela= 13207 file#=4 block#=142731 blocks=126 obj#=98754

•解决办法：

Ø使用oradebug命令手动remaster表：

oradebug lkdebug -m pkey

Ø将oradebug写进ddl triger中

诊断DRM的故障流程：

(1)查看 lmon，lmd，lms和diag进程的trace file

(2)查看AWR/ASH报告

(3)使用hanganalyze和systemstate：

sqlplus '/ as sysdba'

oradebug setorapname reco

oradebugunlimit

oradebug -g all hanganalyze 3

oradebug -g all hanganalyze 3

oradebug -g all dump systemstate 266

oradebug -g all dump systemstate 266

exit