oracle drm阶段,Oracle DRM技术的变迁 （四）

Oracle DRM技术的变迁 (四)

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

如果您在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…