Oracle DRM技术的变迁 (四)

原文链接:  http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_4/

这篇文章不打算做过多的描述,主要看图表说话:(当然反过来说图表也不一定代表事实,例如某声称用事实说话的节目不也经常借着这个幌子向全国人民撒下弥天大谎?)

如果您在metalink上,搜索DRM bug, 将会得到如下结果: (我这里仅仅只是截取了其中的很小的一部分)

 

 

这些bug一来是数量多,而来危害大,我大致总结了下其结局包括以下四类:

 

数据库宕机,节点驱逐, 数据库挂起, ORA-00600。

以前在MOS上有一篇专门的文档, 列举了所有的与DRM相关的bug,不过这篇文章现在已经消失了,我已经不记得那个文档的ID了,只能找到一个非常早的DRM bug列表 (注意这个表格可以翻页):

BUG# FIXED VERSION DESCRIPTION
BUG:5031173 10106 10203 Instance terminated by LMON ORA-602
BUG:4755405 10106 10203 EXCESSIVE WAITS FOR “GCS DRM FREEZE IN ENTER SERVER MODE” IN GSIAT
BUG:4151363 10203 Drop / truncate slow in RAC
BUG:3659289 10105 10201 LMON can fail during remastering sync
BUG:4131113/4948950 10203 ORA-600[KJBMMCHKINTEG:FROM], [32], [32], [1], [1], [3995], [32768]
BUG:5208973 10106 10203 RAC may hang due to deadlock between LMS / MMAN latching
BUG:5414952/5106909 10203 LMS TERMINATING INSTANCE ORA-600 [KJBRASR:PKEY]
BUG:5600050 10204 11106 LMON DIED WITH ORA-600 [525] AND ORA-600
BUG:4903532 9208 10106 10203 RAC instance may be evicted as LMS may not process messages quickly enough
BUG:4639236 10203 OERI [kclcls_5] possible in RAC recreating an object
BUG:6500033 10205 11107 LMON crash the instance with ORA-481 due to DRM sync timeout
BUG:6501007 10204 In RAC a DRM sync timeout may occur due to failing to quiesce a local lock
BUG:6658484 10205 11107 Instance crash / OERI[kclexpand_5] from DRM in RAC
BUG:7905960 10201 THE SERVER PROCESS HANGS WITH ‘GC CR REQUEST’ FOREVER W/O ANY OTHER HOLDER
BUG:5190596 10204 11106 LMON dumps LMS0 too often during DRM leading to IPC send timout
BUG:6960699 10205 11107 INSTANCE CRASHED AFTER LMS1 ENCOUNTERED ORA-600 [KJBLDRMRPST:!MASTER
BUG:6378112 10205 11107 LMS can crash RAC instance with OERI[kjblpkeydrmqscchk:pkey]
BUG:8793912 11202 ORA-600[KJBCLOSE:ISDRM!] OCCURRED IN LMS LEADING TO INSTANCE DOWN
BUG:9448311 11202 BOTH INSTANCE DOWN WITH ORA-481

 

至于那个文档消失的原因, 我想MOS文档DRM – Dynamic Resource management [ID 390483.1]上给出了一句十分隐晦的原因:

DRM attributes are intentionally undocumented since they may change depending on the version. These attributes should not be changed without discussing with Support.

以下是截取的11g DRM引入的read mostly locking新特性的部分bug,当然你可以在MOS中搜索_gc_read_mostly_locking得到更加完整的信息。

 

以下是截取的11g DRM引入的reader bypass新特性的部分bug,可以在MOS中搜索_gc_read_mostly_locking得到更加完整的信息。

 

当然这些并不是DRM的全部关键字,还有一些隐藏得更深:例如pkey, timeout之类的。(一般人我不告诉他)

如果你说你要disable DRM, PM对此的回复是: We have made a lot of improvements that should make it unnecessary to disabled DRM.

Really???对于一个有看buglist习惯的人来说,至少目前这句话是不成立的。以下是最新版本的Oracle PSU中有关于DRM的bug。(没有办法一一列举,只选了几个有代表意义的)。

11.2.0.3.5
13732226 RAC node eviction dur to "TIMEOUT in DRM FREEZE step" or "SYNC TIMEOUT"
13399435 RAC instance eviction due to "TIMEOUT in DRM FREEZE step" or "SYNC TIMEOUT ..."

11.2.0.3.4
13397104 Instance crash with ORA-600 [kjblpkeydrmqscchk:pkey] or similar - superseded
14409183 ORA-600 [kjblpkeydrmqscchk:pkey] or similar / session hangs on "gc buffer busy acquire"

11.2.0.3.3
12879027 LMON gets stuck in DRM quiesce causing intermittent pseudo reconfiguration

有没有目前还没有修复的DRM的bug?

对不起,我只能回答“呵呵”了。

那么如何关闭DRM呢?(以下只提供方法,并不代表任何情况下都需要关闭这个功能, As a guru, you have to learn to chant the magic words “It depends”

在10g中,可以采用如下方式禁用DRM(当然你也可以只禁用其中的一个模块object affinity或者undo affinity)

--disable object affinity
alter system set "_gc_affinity_time"=0 scope=spfile ;
--disable undo affinity
alter system set "_gc_undo_affinity"=FALSE  scope=spfile;

然后同时重启所有实例生效。

如果暂时无法重启实例,可以使用如下命令“事实上”禁用DRM:(以下两个参数可以动态调整)

alter system set “_gc_affinity_limit”=10000000;
alter system set “_gc_affinity_minimum”=10000000;

在11g中,同样可以使用如下方式禁用DRM:

alter system set "_gc_policy_time"=0 scope=spfile;

然后同时重启所有实例生效。如果不想完全禁用DRM,但是需要禁用read-mostly locking或者reader bypass的机制。可以使用如下命令:

--disable read-mostly locking
alter system set "_gc_read_mostly_locking"=false scope=spfile;
--disable reader-bypass
alter system set "_gc_bypass_readers"=false scope=spfile;

Sometimes dancing in a minefield could be an interesting  thing, couldn’t it? although it sounds  a little bit crazy.

未完待续

To Be Continued…


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *