问诊白求恩 - 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