Oracle DRM技术的变迁 (六)

http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_6/

很多童鞋以为之前的DRM专题已经结束了,或者是我已经把它遗忘了。

不!”这次大师你真的错了“。因为真相只有一个:那就是我的思维过于错乱,并且不习惯一次性把所有该说的说完。

以下基于Oracle database 11.2.0.3版本,通过一个烂大街的”magic sql”找到_lm_drm开头的隐含参数:

SELECT x.ksppinm name, y.ksppstvl value, x.ksppdesc description
FROM SYS.x$ksppi x, SYS.x$ksppcv y
WHERE x.inst_id = USERENV ('Instance')
AND y.inst_id = USERENV ('Instance')
AND x.indx = y.indx
AND x.ksppinm LIKE '_lm_drm%'
/

这样我们可以发现有这么一些有意思的参数(不要问我为什么你的库里面有些参数没有,先看看你的版本是不是在11.2.0.3哦,亲)

name value description
_lm_drm_batch_time 10 time in seconds to wait to batch drm requests
_lm_drm_disable 0 disable drm in different level
_lm_drm_hiload_percentage 200 drm high load threshold percentage
_lm_drm_lowload_percentage 200 drm low load threshold percentage
_lm_drm_max_requests 100 dynamic remastering maximum affinity requests processed together
_lm_drm_min_interval 300 minimum interval in secs between two consecutive drms
_lm_drm_object_scan TRUE enable/disable object scan to force full table scan always
_lm_drm_window 0 dynamic remastering bucket window size
_lm_drm_xlatch 0 dynamic remastering forced exclusive latches

尽管最后一栏有对这些隐含参数的描述,但是依然看上去非常隐晦。

以下是数据库在某一负载很高时间段的LMS的trace片段:

 2013-08-14 08:20:56.217
kjm_load_n_health: switch to high load = true (current load 2700)
...
kjm_load_n_health: switch to drm high load = true (current load 2576 )
...

以下对应的LMD的trace文件中的信息:

2013-08-14 07:43:13.751
kjmgetlh: instance 2 switches to high load = false 
...
2013-08-14 08:20:56.224
kjmgetlh: instance 2 switches to high load = true 
... 
2013-08-14 08:38:32.823
kjmgetlh: instance 2 switches to high load = false

可以看到当数据库负载超过某个临界值的时候,DRM就会进入到临时关闭的模式。在负载达到境界水平以下的时候又重新开始进行DRM了。从之前的隐含参数,控制这个两个阈值的开关应该就是_lm_drm_hiload_percentage和_lm_drm_lowload_percentage了。

因此我们得出一个结论:DRM从某一个小版本(应该是在11.2.0.2)有了一些新的衍化,在数据库负载很高的情况下,会暂时禁用DRM,数据库负载下降以后又重新启用DRM。

那么这个负载信息又是如何得到的呢?这个应该是Oracle 11.2 某个小版本开始隐藏的一个新特性叫做load and health check。这个特性是由隐含参数_lm_no_lh_check控制的, 但是load and health check却比这个参数更早出现,只是之前没有提供一个关闭的开关。

请注意:不要未经Oracle support确认的情况下在生产系统上修改上述参数,因为修改隐含参数可能会导致很严重的后果。例如:在通常情况下如果LM*之类的进程挂起,那么LMHB进程会在结束数据库实例以前抓取LM*进程重启的信息。如果将_lm_no_lh_check设置未false,那么则LMHB就不会完成这样的工作,从而导致诊断这类型的故障的时候会缺少很多有用的信息而变得无从下手。

 

未完待续…

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号