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

编辑手记:在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。

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

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-06-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏逸鹏说道

当GitHub把我当成DDos攻击者拉进了黑名单中。。。

Github黑名单自救+快速稳定FQ 异常处理汇总-开发工具 http://www.cnblogs.com/dunitian/p/4522988.html 原...

3408
来自专栏数据和云

【推荐】 RAC 性能优化全攻略与经典案例剖析

ORACLE RAC凭借其卓越的容错能力和可扩展性以及对应用透明的切换能力引领了数据库高可用架构的潮流,但在实际的生产环境中,出现的性能问题非常多,对数据库的稳...

3117
来自专栏Java技术

记一次解决业务系统生产环境宕机问题!

Zabbix告警生产环境应用shutdown,通过堡垒机登入生产环境,查看应用容器进程,并发现没有该业务应用的相应进程,第一感觉进程在某些条件下被系统杀死了,然...

721
来自专栏腾讯DevOps

Git的艺术—分支管理

Git的开发者—— Linus Benedict Torvalds,22岁就创建了Linux系统,发展到2005年的时候,用了仅两周的时间写了一个分布式版本控制...

41810
来自专栏企鹅号快讯

入门干货之用DVG打造你的项目主页-Docfx、Vs、Github

由于这三项技术涉及到的要点以及内容较多,希望大家有空能自己挖掘一下更多更深的用法。 0x01、介绍 VS,即VS2017以及以上版本,宇宙最好的IDE,集成了宇...

2016
来自专栏CBS云硬盘

腾讯云CBS云硬盘使用上的几个小技巧

2541
来自专栏linux、Python学习

IBM技术专家教你“懒惰”Linux管理员的10个关键技巧

好的系统管理员区分在效率上。如果一位高效的系统管理员能在 10 分钟内完成一件他人需要 2 个小时才能完成的任务,那么他应该受到奖励(得到更多报酬),因为他为公...

740
来自专栏Guangdong Qi

黑技术之百度网盘大文件下载直奔主题

2045
来自专栏喵了个咪的博客空间

[Golang软件推荐] Frp内网穿透

在一个IP紧缺的时代,连电信也不分配固定IP给到你用,一条专网专用线路贵的不行,那么作为软件开发人员常常要使用到外网,比如和微信调试程序,给到不在同一网段的朋友...

6804
来自专栏FreeBuf

MacOS再次出现漏洞,号称牢不可破的系统也有弱点

本文讲述了我在苹果的macOS系统内核中发现的几个堆栈和缓冲区溢出漏洞,苹果官方将这几个漏洞归类为内核中的远程代码执行漏洞,因此这些漏洞的威胁级别非常高。攻击者...

802

扫码关注云+社区