RAC 節點參數不一致的示例分析

本篇文章給大家分享的是有關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。

推薦以下文章供大家參考學習：

【新書連載】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 節點參數不一致的示例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。