共計 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 行業資訊頻道。
