原文链接： http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_1/
Oracle的DRM可谓是臭名昭著的一个特性，更是很多DBA谈之色变的一个特性，相信不少dba有在睡梦中半夜被老板/客户的电话叫醒：“赶快过来处理一下，紧急故障，数据库宕机了”。dba半夜打车到客户现场，再alert中发现如下信息：
Mon Mar 14 04:13:13 2011
LMS1 (ospid: 24229) received an instance eviction notification from instance
1 [2]
Mon Mar 14 04:13:13 2011
LMON received an instance eviction notification from instance 1
The instance eviction reason is 0x2
The instance eviction map is 7
Mon Mar 14 04:13:15 2011
PMON (ospid: 24201): terminating the instance due to error 481
同时再LMON的trace中发现如下信息：
********* kjfcrfg() called, BEGIN LMON RCFG *********
kjfcrfg: Pseudo Reconfiguration reason 3 data 0x2
2011-05-09 00:19:06.070487 : * Begin lmon rcfg step KJGA_RCFG_BEGIN
* kjfcrfg: Resource broadcasting enabled
* kjfcrfg: kjfcqiora returned success
kjfcrfg: DRM window size = 1024->1024 (min lognb = 13)
2011-05-09 00:19:06.070640 :
Reconfiguration started (old inc 12, new inc 14)
TIMEOUTS:
Local health check timeout: 70 sec
Rcfg process freeze timeout: 70 sec
Remote health check timeout: 140 sec
Defer Queue timeout: 163 secs
CGS rcfg timeout: 85 sec
Synchronization timeout: 418 sec
DLM rcfg timeout: 1254 sec
这个时候DBA决定了，宁可枉杀三千，不可放过一个。以后我管理的所有的的oracle RAC都把这个特性关闭，并且经验教训写到内部网站上，让集团公司其它的兄弟也看到。从此以后，dba腰也不酸了，背也不疼了，身体倍棒，吃嘛嘛香。这简直可以写一篇Oracle DBA的幸福生活了。
接下来某年某月某日，在MOS（support.oracle.com）Top 5 RAC Instance Crash Issues (Doc ID 1375405.1) 中DRM的大名赫然在列， 顿时觉得神清气爽，回想当初自己的决定是多么英明呀。（当然如果继续深挖，可以找到Top 5 RAC Database/Instance Hang Issues (Doc ID 1389520.1) 也有DRM的身影）。
既然DRM这个功能百害无一益，那么设计DRM的初衷又是啥？请各位看官听我道来，便知原委。
说了半天的DRM，那么有些读者可能会问：“what the hell is DRM?”。 DRM是Dynamic Resource management的简称，意思就是动态资源管理。不过这都是文绉绉的说法，让人摸不着头脑， DRM更通俗的叫法是dynamic remaster，但是什么又是remaster呢？（真是绕呀 !-_-）
首先需要介绍一些RAC机制的基本概念。在Oracle RAC中，所有的数据块（data block）都有一个实例来认领，叫做master，也就是师父。而师父（master）负责照看好自己所管辖的data block的状态。但是师父不是可自由选择的，而是一个叫做相关部门的神秘部门指定。一旦拜师，就不能随便更改，即使要更改也得 ”等到下次数据库重启（restart）或者重组（reconfiguration)。按照中国传统的说法就是 “一日为师，终身为父“， 直到被”逐出师门“。有人肯定相关部门有点好奇，其实相关部门就是上帝。“上帝说要有光，于是便有了光”。同理同为有关部门的发改委不批准，地球敢自传伐？指定和分配就是计划经济时代的产物，美其名曰：“到祖国最需要的地方去”。“上山下乡，援藏援疆“。同样Oracle对每个数据块DBA（data block address）进行hash运算来决定其virtual master，然后再通过查询一个链表，（这张链表保存着virtual master和real master的对应关系）将其转化为real master， 而这张链表的长度就是RAC节点的最大限制数（一般是128，但是具体版本有差异）。这样做的目的是为了当一个节点发生宕机的时候，不需要重新计算所有的数据块master节点，而只需要对本来real master在次节点的数据块进行重新分配。而使用hash算法的目的则是为了保证每个节点得到的数据块数量是差不多的。
等等，诸位看官有没有看出什么问题？ 当然最大的问题肯定是在于有关部门，即初始master节点的指定上。master节点的指定是“父母之命， 媒妁之言” 但并没有真正做到“物尽其用，人尽其才”，解决的办法“恋爱自由，婚姻自由”。 就像某某童话里鼓吹的“ Never Mind， 在遇到自己的Mr Right之前，总会先遇到一些Wrong Guy”。在Oracle中也一样，可能很多人都在Oracle 9i RAC中遇到过这种场景：在一个比较繁忙的RAC生产系统上，db file scatter/sequential read总位于在top wait events，同时还会伴随有global cache cr request，而且这两者存在一个正比的关系。I/O的访问越多， global cache cr request等待就越高。这里又老调重谈，说一说cache fusion，当某个进程需要访问一个或者多个数据块时， oracle首先会检local buffer cache是否存在该块，如果没有，则会向其它实例申请这些块共享访问的权限。一些逻辑比较复杂的sql语句需要访问比较多的对象，必然会有很多数据块的master节点在remote node，所以global cache cr request 变得不可避免。如果有这么一种机制：能随着数据块的访问的频繁程度动态的修改数据块的master节点，那么对应的grant message则会大量的减少。基于以上考虑，DRM特性应运而生。
黑格尔说 “Was vernünftig ist, das ist wirklich; und was wirklich ist, das ist vernünftig.” 翻译为英文就是：“What is rational is actual and what is actual is rational.” 无奈到了某朝只能翻译成了“存在即合理”了。虽然rational和resonable相差十万八千里，牛头不对马嘴。以上废话目的只有一个：DRM机制的产生是为了解决特定的问题，而不是为了引入问题。但是很不幸的是：“理想很丰满，现实很骨感”。早期糟糕的实现几乎毁了DRM。
未完待续
To Be Continued…
Comment