RAC 节点参数不一致的示例分析

共计 2895 个字符，预计需要花费 8 分钟才能阅读完成。

本篇文章给大家分享的是有关 RAC 节点参数不一致的示例分析，丸趣 TV 小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着丸趣 TV 小编一起来看看吧。

在 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 进程数量一致。问题得到解决。

白求恩，从架构到细节，全方位诊断系统安全与健康，比你更了解你的数据库。

以上就是 RAC 节点参数不一致的示例分析，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。