问诊白求恩 - RAC 节点参数不一致引发的悲剧

2017-06-28
219

编辑手记:在Oracle RAC中,有一些参数是数据库级别的,所有实例都使用同一个参数值,有些参数是实例级别的,实例间可以设置不一样的值。然而,对于部分实例级别的参数,节点间设置不同却可能引发故障。


在白求恩智能诊断平台上(https://bethune.enmotech.com),对于数据库参数的检测非常细致,根据参数对于数据库的影响大小,可以分为:性能类参数,稳定性类参数及规范操作类参数。


在我们诊断过程中,发现大部分人在参数的配置上比较随意。最常见的问题包括以下一些:

10g DRM参数配置



在Oracle 10g版本中,开始提出了DRM特性,默认情况下,当某个对象的被访问频率超过50时,而同时该对象的master又是其他节点时,那么Oracle则会触发DRM操作来修改master节点,这样的好处是可以大幅降低gc grant之类的等待事件。


在进程DRM操作的过程中,Oracle会将该资源的相关信息进行临时frozen,然后将该资源在其他节点进行unfrozen,然后更改资源的master节点。由于frozen的资源是GRD(Global Resource Directory)中的资源。在整个DRM的过程之中,访问该资源的进程都将被临时挂起。正因为如此,当系统出现DRM操作时,很可能导致系统或进程出现异常的。


Oracle DRM的Bug也非常多,尤其是Oracle 10gR2版本中,因此在10g的生产环境中,我们一般是建议关闭DRM特性的。


关闭DRM,常规的操作是:

_gc_affinity_time=0  

_gc_undo_affinity=FALSE  


但这2个参数是静态参数,也就是说必须要重启实例才能生效。实际上可以设置另外2个动态的隐含参数,来达到这个目的。

_gc_affinity_limit=250  

_gc_affinity_minimum=10485760  


甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM。


推荐以下文章供大家参考学习:

【新书连载】DRM引发RAC的故障分析

【深入解析】DRM和read-mostly locking

【细致入微】Oracle RAC DRM引起性能问题案例一则


RAC 全局事务处理


集群范围全局性事务(Clusterwide global transactions)是11g的新特性。集群范围全局性事务指的是在RAC中的每个节点均有一个本地事务,它属于一种分布式事务,当_clusterwide_global_transactions=true(default)时,Oracle会把这些本地事务当做一个事务对待,当_clusterwide_global_transactions=false时,Oracle会将这些本地事务当做单独的事务通过多阶段提交协调处理。


在默认设置为TRUE的情况下,可能会遭遇以下bug.
Bug 13605839 ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC
ORA-00600: [kjuscl:!free]


因此,建议将该参数修改为FALSE,修改后不会对性能产生任何影响。


节点间LMS不一致引发的故障

LMS进程主要负责节点之间的数据交互,是RAC中最忙碌是一个进程。其默认值由系统的CPU数量计算得出,不同版本中的计算方法有差异。也可以通过gcs_server_process参数进行配置。一般情况下,要求节点之间的LMS进程数量一致。


接下来分享一个跟LMS相关的故障。


情景描述:一个批量执行的业务,时快时慢,经检查在执行计划完全一致的情况下,执行时间在2hour ~10hour 不等。


采样AWR报告,整体DBtime如下:


而这些DBtime主要消耗在RAC Global Cache环节。



这里对gc current grant 2-way等待事件简单说明:

gc cr&current grant 2-way 是一种 grant message package 的传递,当取cr 或current block 时向block master instance 请求x或s的权限 ,当请求的block在从任何实例上的buffer cache中都没有发现, lms进程会通知FG进程从disk 读取block到local buffer cache中


节点之间的等待如此长,是不是节点流量过大所以产生等待呢?


然而事实并不是这样,节点间流量很小。那么为什么会产生如此多的等待。


我们来分析RAC的Global Cache环节到底在做什么?


以cr块的访问为例,

Avg global cache cr block receive time=

Avg global cache cr block build time+

Avg global cache cr block send time+

Avg global cache cr block flush time+

Avg message sent queue time on ksxp+

其他


在上图中,我们发现以下四项相加的时间仅为0+0+3.1+0.2=3.3,与消耗的总时间87相差甚远。那么时间都到哪里去了?


我们通过AWR报告继续分析RAC的全局统计信息

我们发现,在最后一行,出现了流量控制,高达16.28。此处的数据为系统运行最慢的时候的,那么对比运行正常的时候发现,正常情况下,流量控制的值为0.8.


所以,16.28 vs 0.8.这是问题的关键!


但是,根据前面的分析,节点之间的流量并不大,为什么会做流量控制?

一把情况下,节点间做流量控制的原因有以下几条

1、私网网络链路不通畅

2、RAC对端节点负载较高

3、两个节点的传输配置有差异


在这个案例中,前两者都不存在问题。那么就是两个节点的传输配置有差异。我们知道,节点之间数据传输是LMS进程执行的,因此,说明了LMS的配置有差异。


我们查询gcs_server_process 参数,发现没有配置。然后查看CPU数量,结果如下


果然是CPU不对等,因此,在lms 多的节点上(本案例的节点1 ) 有更强的cache fusion 请求的能力疯狂的抛向LMS进程小的节点(节点2)时, 节点2 的负载过重无法对称的处理, 就会出现这个性能问题。


Oracle为了避免这种攻击的产生,于是做了流量控制,导致系统中大量等待。


最后,我们手动修改了gcs_server_process 参数,使得LMS进程数量一致。问题得到解决。


白求恩,从架构到细节,全方位诊断系统安全与健康,比你更了解你的数据库。现在登录立即体验:https://bethune.enmotech.com

加入"云和恩墨大讲堂"微信群,参与讨论学习

搜索 盖国强(Eygle) :eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。


关注微信,获得后续精彩分享

最后修改时间:2020-05-07 23:55:36
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论