原文链接: 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"
psu3
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…