RAC之間消息傳輸流量控制

RAC系統中,對於節點和節點之間數據塊一致性的保證是經過消息的機制來保證的,也就是咱們常說的gcs和ges的這些消息來確保的。這些消息分別有LMDLMS的進程在實例之間進行傳輸。oracle

LMD負責處理message的信息,如塊的狀態,lock level等信息。而LMS會負責數據塊的傳輸。咱們這不討論一致性的機制,主要關注在消息傳輸的流量和控制上。日誌

無論是LMS仍是LMD的消息傳遞,這些信息傳輸,都是經過UDP的協議透過私網進行消息的傳遞的。而在實例之間進行消息傳輸的時候,消息的傳遞是彼此交互式的,不能由一個節點一直髮送,而另一個節點只負責持續的負責接收。因此在實例之間傳輸的時候就要平衡,傳輸消息的概率,控制彼此之間的合理流量,RAC裏經過引入ticket的概念對彼此之間傳輸的流量和概率進行控制。blog

對於ticket概念的理解和best practice,Oracle有兩篇相關文檔能夠參考:隊列

Resolving ORA-481 and "terminating the instance due to error 481" (Doc ID 1950963.1)進程

Best Practices and Recommendations for RAC databases using very large SGA(e.g. 100 GB) (Doc ID 1619155.1)文檔

這裏咱們能夠看到,Oracle是經過某一個節點持有的ticket的數量對發送和接受消息進行流量控制的。一個節點發送一則消息隊列的同時會帶着一個ticket到對端,對端的ticket會增長。本地的ticket會減小,本地節點會根據可用的buffer和已經收到的信息以及發送的請求ticket的信息(null-req)計算本地可用的tickets。當本地沒有ticket可用,本地的LMS/LMD就會進入消息等待隊列,並持續的檢查ticket latch裏的信息,判斷是否有可用的ticket的信息可用。直到對端發送回message,並帶回可用的tickets後,本地才能再繼續發送消息到對端。get

咱們能夠查詢動態視圖:GV$GES_TRAFFIC_CONTROLLER 來獲取每一個節點上avalible的tickets數量,而且能夠經過TCKT_WAIT判斷LMS或者LMD是否正在等待ticket。若是咱們持續的看到這裏彼此都在等待,說明UDP buffer裏package信息,沒有被及時的處理,或者在傳輸的過程丟掉了。固然,咱們也能夠憑經驗看lms/lmd在crash以前裏的隊列的消息傳輸狀況來判斷是不是ticket不足引起的問題。這不如直接獲取的GV$GES_TRAFFIC_CONTROLLER直觀。消息隊列

咱們最爲常見的問題就是:it

1. RAC hang / LMD crashes instance with ORA-600[kjmscndscq:timeout] (Doc ID 1619155.1)io

2. ORA-00481 After "The instance eviction reason is 0x2" due to Lack of Ticket (Doc ID 1644015.1)

這兩個問題相對比較明顯:

告警日誌中:ORA-600[kjmscndscq:timeout]或者 ora-00481錯誤以前提示的"The instance eviction reason is 0x2"

都是說明實例之間的因爲tickets短缺,引起了LMS/LMD之間的消息傳輸超時出現的故障。

這種問題在HP的平臺上尤其明顯,由於HP平臺上的LMS通常都不是真正的RR(real time)模式的進程,致使LMS沒能獲得CPU的及時調度。關於進程優先級的問題,請參考如下文檔: HP-UX: HPUX_SCHED_NOAGE and Scheduling Priority-Policy for LMS in RAC (Doc ID 759082.1)

因此對於HP的平臺上的用戶,若是SGA區比較大(一般超過100G),業務頻繁在多個節點上更新相同的表活數據塊,是很容易遇見此類問題的。

如下文檔給出了大部分的解決方案:

ORA-00481 After "The instance eviction reason is 0x2" due to Lack of Ticket (Doc ID 1644015.1)

Best Practices and Recommendations for RAC databases using very large SGA(e.g. 100 GB) (Doc ID 1619155.1)

若是您在12.1.0.2的版本上運行您的系統,須要注意的是LMD進程在各個節點之間要保持數量一致(默認的個數是和CPU個數相關的),若是LMD個數不一樣,須要打補丁17821214。

相關文章
相關標籤/搜索