13518219792
本篇文章给大家分享的是有关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¤t 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 节点参数不一致的示例分析，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联-成都网站建设公司行业资讯频道。
