原文链接: 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…
Leave a Reply