RAC 節(jié)點(diǎn)參數(shù)不一致的示例分析

本篇文章給大家分享的是有關(guān)RAC 節(jié)點(diǎn)參數(shù)不一致的示例分析，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

在Oracle RAC中，有一些參數(shù)是數(shù)據(jù)庫級(jí)別的，所有實(shí)例都使用同一個(gè)參數(shù)值，有些參數(shù)是實(shí)例級(jí)別的，實(shí)例間可以設(shè)置不一樣的值。然而，對(duì)于部分實(shí)例級(jí)別的參數(shù)，節(jié)點(diǎn)間設(shè)置不同卻可能引發(fā)故障。

在白求恩智能診斷平臺(tái)上（https://bethune.enmotech.com），對(duì)于數(shù)據(jù)庫參數(shù)的檢測(cè)非常細(xì)致，根據(jù)參數(shù)對(duì)于數(shù)據(jù)庫的影響大小，可以分為：性能類參數(shù)，穩(wěn)定性類參數(shù)及規(guī)范操作類參數(shù)。

在我們?cè)\斷過程中，發(fā)現(xiàn)大部分人在參數(shù)的配置上比較隨意。最常見的問題包括以下一些：

10g DRM參數(shù)配置

在Oracle 10g版本中，開始提出了DRM特性，默認(rèn)情況下，當(dāng)某個(gè)對(duì)象的被訪問頻率超過50時(shí)，而同時(shí)該對(duì)象的master又是其他節(jié)點(diǎn)時(shí)，那么Oracle則會(huì)觸發(fā)DRM操作來修改master節(jié)點(diǎn)，這樣的好處是可以大幅降低gc grant之類的等待事件。

在進(jìn)程DRM操作的過程中，Oracle會(huì)將該資源的相關(guān)信息進(jìn)行臨時(shí)frozen，然后將該資源在其他節(jié)點(diǎn)進(jìn)行unfrozen，然后更改資源的master節(jié)點(diǎn)。由于frozen的資源是GRD（Global Resource Directory）中的資源。在整個(gè)DRM的過程之中，訪問該資源的進(jìn)程都將被臨時(shí)掛起。正因?yàn)槿绱?，?dāng)系統(tǒng)出現(xiàn)DRM操作時(shí)，很可能導(dǎo)致系統(tǒng)或進(jìn)程出現(xiàn)異常的。

Oracle DRM的Bug也非常多，尤其是Oracle 10gR2版本中，因此在10g的生產(chǎn)環(huán)境中，我們一般是建議關(guān)閉DRM特性的。

關(guān)閉DRM，常規(guī)的操作是:

_gc_affinity_time=0  

_gc_undo_affinity=FALSE  

但這2個(gè)參數(shù)是靜態(tài)參數(shù)，也就是說必須要重啟實(shí)例才能生效。實(shí)際上可以設(shè)置另外2個(gè)動(dòng)態(tài)的隱含參數(shù)，來達(dá)到這個(gè)目的。

_gc_affinity_limit=250  

_gc_affinity_minimum=10485760  

甚至可以將以上2個(gè)參數(shù)值設(shè)置得更大。這2個(gè)參數(shù)是立即生效的，在所有的節(jié)點(diǎn)上設(shè)置這2個(gè)參數(shù)之后，系統(tǒng)不再進(jìn)行DRM。

推薦以下文章供大家參考學(xué)習(xí)：

【新書連載】DRM引發(fā)RAC的故障分析

【深入解析】DRM和read-mostly locking

【細(xì)致入微】Oracle RAC DRM引起性能問題案例一則

RAC 全局事務(wù)處理

集群范圍全局性事務(wù)(Clusterwide global transactions)是11g的新特性。集群范圍全局性事務(wù)指的是在RAC中的每個(gè)節(jié)點(diǎn)均有一個(gè)本地事務(wù)，它屬于一種分布式事務(wù)，當(dāng)_clusterwide_global_transactions=true(default)時(shí)，Oracle會(huì)把這些本地事務(wù)當(dāng)做一個(gè)事務(wù)對(duì)待，當(dāng)_clusterwide_global_transactions=false時(shí)，Oracle會(huì)將這些本地事務(wù)當(dāng)做單獨(dú)的事務(wù)通過多階段提交協(xié)調(diào)處理。

在默認(rèn)設(shè)置為TRUE的情況下，可能會(huì)遭遇以下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]

因此，建議將該參數(shù)修改為FALSE，修改后不會(huì)對(duì)性能產(chǎn)生任何影響。

節(jié)點(diǎn)間LMS不一致引發(fā)的故障

LMS進(jìn)程主要負(fù)責(zé)節(jié)點(diǎn)之間的數(shù)據(jù)交互，是RAC中最忙碌是一個(gè)進(jìn)程。其默認(rèn)值由系統(tǒng)的CPU數(shù)量計(jì)算得出，不同版本中的計(jì)算方法有差異。也可以通過gcs_server_process參數(shù)進(jìn)行配置。一般情況下，要求節(jié)點(diǎn)之間的LMS進(jìn)程數(shù)量一致。

接下來分享一個(gè)跟LMS相關(guān)的故障。

情景描述：一個(gè)批量執(zhí)行的業(yè)務(wù)，時(shí)快時(shí)慢，經(jīng)檢查在執(zhí)行計(jì)劃完全一致的情況下，執(zhí)行時(shí)間在2hour ~10hour 不等。

采樣AWR報(bào)告，整體DBtime如下：

而這些DBtime主要消耗在RAC Global Cache環(huán)節(jié)。

這里對(duì)gc current grant 2-way等待事件簡單說明：

gc cr&current grant 2-way 是一種 grant message package 的傳遞，當(dāng)取cr 或current block 時(shí)向block master instance 請(qǐng)求x或s的權(quán)限 ，當(dāng)請(qǐng)求的block在從任何實(shí)例上的buffer cache中都沒有發(fā)現(xiàn), lms進(jìn)程會(huì)通知FG進(jìn)程從disk 讀取block到local buffer cache中

節(jié)點(diǎn)之間的等待如此長，是不是節(jié)點(diǎn)流量過大所以產(chǎn)生等待呢？

然而事實(shí)并不是這樣，節(jié)點(diǎn)間流量很小。那么為什么會(huì)產(chǎn)生如此多的等待。

我們來分析RAC的Global Cache環(huán)節(jié)到底在做什么？

以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+

其他

在上圖中，我們發(fā)現(xiàn)以下四項(xiàng)相加的時(shí)間僅為0+0+3.1+0.2=3.3，與消耗的總時(shí)間87相差甚遠(yuǎn)。那么時(shí)間都到哪里去了？

我們通過AWR報(bào)告繼續(xù)分析RAC的全局統(tǒng)計(jì)信息

我們發(fā)現(xiàn)，在最后一行，出現(xiàn)了流量控制，高達(dá)16.28。此處的數(shù)據(jù)為系統(tǒng)運(yùn)行最慢的時(shí)候的，那么對(duì)比運(yùn)行正常的時(shí)候發(fā)現(xiàn)，正常情況下，流量控制的值為0.8.

所以，16.28 vs 0.8.這是問題的關(guān)鍵！

但是，根據(jù)前面的分析，節(jié)點(diǎn)之間的流量并不大，為什么會(huì)做流量控制？

一把情況下，節(jié)點(diǎn)間做流量控制的原因有以下幾條：

1、私網(wǎng)網(wǎng)絡(luò)鏈路不通暢

2、RAC對(duì)端節(jié)點(diǎn)負(fù)載較高

3、兩個(gè)節(jié)點(diǎn)的傳輸配置有差異

在這個(gè)案例中，前兩者都不存在問題。那么就是兩個(gè)節(jié)點(diǎn)的傳輸配置有差異。我們知道，節(jié)點(diǎn)之間數(shù)據(jù)傳輸是LMS進(jìn)程執(zhí)行的，因此，說明了LMS的配置有差異。

我們查詢gcs_server_process 參數(shù)，發(fā)現(xiàn)沒有配置。然后查看CPU數(shù)量，結(jié)果如下

果然是CPU不對(duì)等，因此，在lms 多的節(jié)點(diǎn)上(本案例的節(jié)點(diǎn)1 ) 有更強(qiáng)的cache fusion 請(qǐng)求的能力瘋狂的拋向LMS進(jìn)程小的節(jié)點(diǎn)（節(jié)點(diǎn)2）時(shí)， 節(jié)點(diǎn)2 的負(fù)載過重?zé)o法對(duì)稱的處理， 就會(huì)出現(xiàn)這個(gè)性能問題。

Oracle為了避免這種攻擊的產(chǎn)生，于是做了流量控制，導(dǎo)致系統(tǒng)中大量等待。

最后，我們手動(dòng)修改了gcs_server_process 參數(shù)，使得LMS進(jìn)程數(shù)量一致。問題得到解決。

白求恩，從架構(gòu)到細(xì)節(jié)，全方位診斷系統(tǒng)安全與健康，比你更了解你的數(shù)據(jù)庫。

以上就是RAC 節(jié)點(diǎn)參數(shù)不一致的示例分析，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。