DRM 分析及案例讲解

   DRM（Dynamic Resource management）是oracle10.10.2里面推出来的一个新特性，一直到现在最新的12cR1，都存在，且bug非常多而著称。在10gR1 RAC是每个实例都有其自己的SGA和buffer cache。RAC为了确保这些块发生时的最大化性能,确保数据完整。每个缓冲区副本也称为缓存资源有一个主要的将做为一个主要的集群节点。在数据库版本10g(10.1.0.2)一个主要的缓存资源负责掌管一个实例,re-mastering或改变主节点只会发生在重新配置,会自动在两个正常操作实例启动或实例关闭，异常节点集群管理器将对其进行逐出。因此,如果节点B这个时候作为一个主缓存的资源,这个资源仍将掌握在节点B直到重新配置。10g中引入了一个新概念,通过DRM资源进行remaster。与DRM资源可以在另一个节点上重新优化,从节点B节点如果发现更频繁地访问缓存资源从节点a重新配置不再是资源重新优化的唯一原因。

到10gR2是基于相关对象的，下面是DRM的跟踪trace文件，在Oracle日志中的LMD进程信息里面。

Begin DRM(202) - transfer pkey 4294951314 to0 oscan 1.1 
*** 2006-08-01 17:34:54.645 
Begin DRM(202) - transfer pkey 4294951315 to 0 oscan 1.1 
*** 2006-08-01 17:34:54.646 
Begin DRM(202) - transfer pkey 4294951316 to 0 oscan 1.1 
*** 2006-08-01 17:34:54.646 
Begin DRM(202) - transfer pkey 4294951317 to 0 oscan 1.1

 

    Remastering问题发生时会影响性能。以下AWR报告显示了DRM重配置问题导致的实例冻结。同样类型的冻结在其它的所有节点上也都可以看见。gc buffer busy等待只是DRM冻结的副作用（不是总有，但是在这个case是这样）。

Top 5 Timed Events Avg %Total

~~~~~~~~~~~~~~~~~~ wait Call

Event Waits Time (s) (ms) Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

gc buffer busy 1,826,073 152,415 83 62.0 Cluster

CPU time 30,192 12.3

enq: TX - index contention 34,332 15,535 453 6.3 Concurrenc

gcs drm freeze in enter server 22,789 11,279 495 4.6 Other

enq: TX - row lock contention 46,926 4,493 96 1.8 Applicatio

   在同一时刻，DRM大量发生，导致了重复的DRM冻结、实例重配置，从而引发严重的性能问题。

Top 5 Timed Events Avg %Total

~~~~~~~~~~~~~~~~~~ wait Call

Event Waits Time (s) (ms) Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

latch: cache buffers lru chain 774,812 140,185 181 29.7 Other

gc buffer busy 1,356,786 61,708 45 13.1 Cluster

latch: object queue header ope 903,456 55,089 61 11.7 Other

latch: cache buffers chains 360,522 49,016 136 10.4 Concurrenc

gc current grant busy 112,970 19,893 176 4.2 Cluster

可以看到，TOP 5中，有3个是latch相关的等待，而另外2个则是跟RAC相关的等待。
如果再查看更细的等待数据，可以发现其他问题：

 Avg

 %Time Total Wait wait Waits

Event Waits -outs Time (s) (ms) /txn

---------------------------- -------------- ----- ----------- ------- ---------

latch: cache buffers lru cha 774,812 N/A 140,185 181 1.9

gc buffer busy 1,356,786 6 61,708 45 3.3

latch: object queue header o 903,456 N/A 55,089 61 2.2

latch: cache buffers chains 360,522 N/A 49,016 136 0.9

gc current grant busy 112,970 25 19,893 176 0.3

gcs drm freeze in enter serv 38,442 97 18,537 482 0.1

gc cr block 2-way 1,626,280 0 15,742 10 3.9

gc remaster 6,741 89 12,397 1839 0.0

row cache lock 52,143 6 9,834 189 0.1

    从上面的数据还可以看到，除了TOP 5等待，还有”gcs drm freeze in enter servermode“以及”gc remaster”这2种比较少见的等待事件，从其名称来看，明显与DRM有关。那么这2种等待事件与TOP5的事件有没有什么关联？。MOS文档”Bug 6960699- “latch: cache buffers chains” contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/OERI[kjbldrmrpst:!master] [ID 6960699.8]”提及，DRM的确可能会引起大量的”latch: cache buffers chains”、”latch: objectqueue header operation”等待，虽然文档没有提及，但不排除会引起”latch: cachebuffers lru chain“这样的等待。

    为了进一步证实性能问题与DRM相关，使用tail -f命令监控LMD后台进程的trace文件。在trace文件中显示开始进行DRM时，查询v$session视图，发现大量的 “latch: cache buffers chains” 、”latch:object queue header operation”等待事件，同时有”gcs drm freezein enter server mode“和”gc remaster”等待事件，同时系统负载升高，前台反映性能下降。而在DRM完成之后，这些等待消失，系统性能恢复到正常。

* received DRM start msg from 2 (cnt 5, last 1, rmno 404)

Rcvd DRM(404) Transfer pkey 1598477 from 3 to 2 oscan 1.1

Rcvd DRM(404) Dissolve pkey 6100030 from 2 oscan 0.1

Rcvd DRM(404) Dissolve pkey 5679943 from 2 oscan 0.1

Rcvd DRM(404) Transfer pkey 6561036 from 0 to 2 oscan 1.1

Rcvd DRM(404) Transfer pkey 5095243 to 2 oscan 0.1

  A small test case 
   我们来看一个测试，观察一下DRM的产生。使用了索引读路径的查询从一个大索引中读取了几乎所有数据块。

Session #1:

select data_object_id from dba_objects where object_name=WMS_N1;

DATA_OBJECT_ID

-------------

6099472


ADDR INDX INST_ID OBJECT NODE OPENS

---------------- ---------- ---------- ---------- ---------- ----------

FFFFFFFF7C05BFA8 14 1 6099472 1 23442


select * from x$object_affinity_statistics where object=6099472;

ADDR INDX INST_ID OBJECT NODE OPENS

---------------- ---------- ---------- ---------- ---------- ----------

FFFFFFFF7C05BFA8 16 1 6099472 1 33344


ADDR INDX INST_ID OBJECT NODE OPENS

---------------- ---------- ---------- ---------- ---------- ----------

FFFFFFFF7C05BFA8 0 1 6099472 1 1229


 FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT

---------- ---------- -------------- --------------- ------------

 0 6099472 0 32767 1


ADDR INDX INST_ID OBJECT NODE OPENS

---------------- ---------- ---------- ---------- ---------- ----------

FFFFFFFF7C05AF78 2 1 6099472 1 42335

FFFFFFFF7C05AF78 3 1 6099472 2 1


Begin DRM(411) - transfer pkey 6099472 to 0 oscan 0.0

 ftd received from node 1 (4/0.30.0)

 all ftds received


ADDR INDX INST_ID OBJECT NODE OPENS

---------------- ---------- ---------- ---------- ---------- ----------

FFFFFFFF7C05BFA8 0 1 6099472 1 7437


 FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT

---------- ---------- -------------- --------------- ------------

 0 6099472 0 32767 1

我们的测试表明，该索引上发生了大量的BL锁请求，之后对象被remastering。

Undo and affinity
   回滚段的Mastering和其它段不同。对于非回滚段而言，一个段上的所有数据块通过哈希算法被分散在各个实例间。只有在经过大量的BL锁请求以后，段才会被mastering。但是对于回滚段而言，激活了一个回滚段的实例立刻成为该段的属主。这是合乎情理的，因为在大多数情况下回滚段将会被打开这个segment的实例使用。初始化参数_gc_undo_affinity控制这种动态undo remastering动作是否发生。

   因为回滚段没有真正的object_id，所以使用4294950912作为虚拟object_ids的基准值。比如说，回滚段1（usn=1）的object_id是4294950913，回滚段2（usn=2）的object_id就是4294950914，依次类推（4294950912 = power(2,32) – power (2,14)= xFFFFC000）。

select objecT_id, object_id-4294950912 usn, current_master, previous_master,

remaster_cnt from v$gcspfmaster_info where object_id 4294950912;


 OBJECT_ID USN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT

---------- ---------- -------------- --------------- ------------

4294950913 1 0 32767 1

4294950914 2 0 32767 1

4294950915 3 0 32767 1

4294950916 4 0 32767 1

4294950917 5 0 32767 1

4294950918 6 0 32767 1

4294950919 7 0 32767 1

4294950920 8 0 32767 1

4294950921 9 0 32767 1

4294950922 10 0 32767 1

4294950923 11 1 32767 1

4294950924 12 1 32767 1

4294950925 13 1 32767 1





  我没有成功试验出触发下一次回滚段remastering。我创建了一个活动事务在一个节点上产生了200K回滚数据块，然后另外一个节点在读这个表，我观察到在回滚数据块上有大量等待。但是我没有发现这个回滚段上有任何remastering事件。无法确认为什么没有产生，也许是回滚段remastering的条件有所不同吧。

译者注：回滚段的remastering是不会因为另外一个节点对于回滚段有大量读取而发生的，只有在某个实例失效，然后负责进行实例恢复的另外那个实例会暂时的成为这些回滚段的master，这是为了进行实例恢复的需要，在恢复完毕以后所有的undo

 buffers都会被flush到磁盘上。


PS：我能够使用后面将描述的lkdebug命令手动remaster回滚段，所以oracle也应该可以自动remaster回滚段，只是可能还有一个其它条件也必须满足。


select * from v$gcspfmaster_info where object_id=431+4294950912;

 FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT

---------- ---------- -------------- --------------- ------------

 0 4294951343 0 32767 1


 FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT

---------- ---------- -------------- --------------- ------------

 0 4294951343 1 0 2






  我不是在劝你们应该去修改这些隐含参数。只是要去理解这些参数，如果你们碰到诸如’gc remaster’, ‘gcs freeze for instancereconfiguration’这样的等待事件，那么应该知道是不是因为默认值太低了。跟技术支持沟通尝试是否能够调整。

Manual remastering
你可以使用oradebug命令来手动remaster一个对象：


oradebug lkdebug -m pkey

这会将一个对象remaster请求放入队列。LMD0和LMON进程会完成这个请求。


当前属主是从0开始计数的。




*** 2010-01-08 23:25:54.948

* received DRM start msg from 1 (cnt 1, last 1, rmno 191)

Rcvd DRM(191) Transfer pkey 6984154 from 0 to 1 oscan 0.0

ftd received from node 1 (8/0.30.0)

ftd received from node 0 (8/0.30.0)

ftd received from node 3 (8/0.30.0)


FILE_ID OBJECT_ID CURRENT_MASTERPREVIOUS_MASTER REMASTER_CNT 

---------- ---------- ----------------------------- ------------ 

0 6984154 1 0 2 


FILE_ID OBJECT_ID CURRENT_MASTERPREVIOUS_MASTER REMASTER_CNT 

---------- ---------- ----------------------------- ------------ 

0 6984154 2 1 3 




Summary


总结一下，remarstering是个很棒的功能。不过遗憾的是，我们有时候会成为它负面效果的受害者。所以，如果你碰到remastering引起的问题，不要直接就禁用它，而是应该去看看能否调优那些参数从而控制remastering事件。如果你仍然想完全禁用DRM，那么我建议设置_gc_affinity_limit和_gc_affinity_minimum参数到一个较高值，比如说1千万。将参数_gc_affinity_time设置为0也可以完全禁用DRM，但是这也意味着再也无法手工remaster对象了。另外，Arup也提到如果DRM被禁用那么x$object_affinity_statistics表也不会再被维护。

Update 1:


从11g开始，affinity管理更名为policy管理（策略管理）。比如说，x$object_affinity_statistics表改名为x$object_policy_statistics，与之相似的，初始化参数也发生了改变：参数_gc_affinity_limit改名为_gc_policy_limit；参数_gc_affinity_time改名为_gc_policy_time；出现了一个新的视图v$policy_history，其中所有policy_event = ‘initiate_affinity’的记录都是与DRM事件相关的。


本blog的其它部分仍然没问题，除了默认的_gc_policy_limit参数值降低为1500，这意味着，在理论上，11g可能会产生更多的DRM事件。 



select * from v$policy_history

 INST_ID POLICY_EVENT DATA_OBJECT_ID TARGET_INSTANCE_NUMBER EVENT_DATE

---------- -------------------- -------------- ---------------------- --------------------

 2 glru_on 0 1 10/15/2010 10:58:28

 2 glru_on 0 1 10/15/2010 11:21:32

 2 initiate_affinity 74809 1 10/15/2010 13:27:44




看起来，只需要关闭DRM就能避免这个问题。怎么样来关闭/禁止DRM呢？很多MOS文档提到的方法是设置2个隐含参数：


_gc_affinity_time=0

_gc_undo_affinity=FALSE



不幸的是，这2个参数是静态参数，也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数，来达到这个目的。按下面的值设置这2个参数之后，不能完全算是禁止/关闭了DRM，而是从”事实上“关闭了DRM。








甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的，在所有的节点上设置这2个参数之后，系统不再进行DRM，经常一段时间的观察，本文描述的性能问题也不再出现。

 

11g

_gc_policy_limit=1500

_gc_policy_time=0



 


参考：


http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_1/


http://www.dbform.com/html/tag/drm


http://wenku.baidu.com/link?url=DykRyVGrvpLkfHUMrgoUOKghYXLAzh3YRSu1AHksMwdSmL5b8XtEcEocQcC7ziRrzd6OF54w9w4TBHuHo486MsXwJFhBrtKe5r3jdtA8joS


http://www.laoxiong.net/problem-caused-by-drm.html



  考勤系统的最佳实践 - 静态活体检测 API 技术 

 静态活体检测（Static Liveness Detection）API 是一种基于人脸识别技术，用于判断面部图像或视频是否为真实人脸的 API 接口。它基于图片中人像的破绽（摩尔纹、成像畸形等），判断目标是否为活体，有效防止屏幕二次翻拍等作弊攻击，它广泛应用于门禁、考勤、电子签名等场景中，以确保安全的身份验证和授权过程。


  什么是受 DRM 保护的内容? 

 当谈到数字媒体世界中的内容时，您当然需要借助 DRM（数字版权管理）技术来保护您的创作或内容。让我们简要了解什么DRM以及什么是受 DRM 保护的内容。


  常见流媒体服务器方案对比分析 

 目前，市面上有很多开源的流媒体服务器解决方案，常见的有 SRS、EasyDarwin、ZLMediaKit 和 Monibuca 等，我们应该怎么选择呢？今天这篇文章主要介绍 SRS、EasyDarwin、ZLMediaKit 和 Monibuca 的一些对比情况，可以作为日后调研选型和学习的参考文档。


  网站和APP渗透测试人工审计的优势覆盖分析 

 在前面解决了人工服务网站渗透测试的缺点，工作效率、多次重复、忽略等难题后，也使我们能从原先对1个APP的安全系数提升到接口技术参数级別。这里边简单化了原先人工服务网站渗透测试时搜集资产和寻找疑是安全风险两一部分工作任务，另外一部分漏洞立即依据数据流量就可以立即明确掉。但因为漏洞的不同形状，依然会存有许多安全风险需要更进一步明确是不是真正存有，这方面的工作效率也需要再次提高。


  APP性能监测工具之友盟的 U-APM产品入门使用 

 最近公司做了一款新的APP，要求能够看到用户每天的新增量和活跃量，还有一些页面的点击量、停留时间等的监测，还有更重要的一点就是能够监测到app的异常情况。于是开始对第三方工具开始一番研究，对比之后我选择使用了友盟。


  播放器支持商业DRM实战（二）—— 支持WideVine 

 ### 一. WideVine简介

在收购Widevine之前，Android没有系统的数字版权保护机制，2010年12月，Google不惜重金将视频数字版权管理软件公司Widevine招安，弥补了Android在这方面的短板。Android从3.0开始就支持Widevine。现在Widevine已经成为GMS（Google Mobile Service）中必备的内容，所有想要得到GMS的手机厂商


  GATK 软件分析流程 

 GATK 软件分析流程由阿里云和 Broad Institute 合作提供。Broad Institute 提供的 GATK 流程最佳实践用 工作流定义语言（WDL） 编写，通过批量计算集成的 Cromwell 工作流引擎解析执行。用户将为作业运行时实际消耗的计算和存储资源付费，不需要支付资源之外的附加费用。

Broad Institute GATK 网站和论坛为 GATK 工具和 WDL 提供了更完整的背景信息，文档和支持。

如果需要执行用 WDL 编写的通用工作流程，请参考 cromwell 工作流引擎和 WDL 支持的 APP 。


  动态贴纸SDK怎样开发才能接入运营级别短视频平台 

 以抖音、快手为例的短视频平台是大众都非常喜爱的娱乐消遣方式之一，除了新颖有趣的视频拍摄玩法和变现方式之外，其接入的动态贴纸SDK也成为了提升用户留存率的主要“工具”之一。那么，怎样开发动态贴纸SDK才能使其具备接入运营级短视频平台的“资格”？


  iOS多渠道统计方案详解 

 iOS的“渠道”通常是指那些在其它 App 或者网页内部，提供到达 App Store 的链接的页面。因此，在 iOS 中追踪发行渠道，主要是追踪进入 App Store 相关页面的渠道信息。从技术角度来看，也就是在用户首次下载时不仅要获取下载来源，还要实现参数传递，简单来说，就是用户第一次下载后，我能得知后续的注册、活跃、付费等操作行为。


 prudentwoo

 10g/11g OCP 11g OCM，ITPUB和CSDN专家及专家讲师；有着多年数据库从业经验，资深Oracle数据库专家，现就职于北京海量数据技术股份有限公司担任高级dba职务，为央视，银行，电信等各行业及企业提供过技术支持服务