二月技術通訊.pdf丨核心資料庫一波三折異常重啟分析

  • 2020 年 2 月 26 日
  • 筆記

每月關註：55 頁 乾貨，匯總一個月資料庫行業熱點事件、新的產品特性，包括重要資料庫產品發布、警報、更新、新版本、修補程式等。

親愛的讀者朋友：

為了及時共享行業案例，通知共性問題，達成共享和提前預防，以及共同學習國產資料庫內容，我們整理和編輯了《雲和恩墨技術通訊》，通過對過去一段時間的知識回顧，故障歸納，以期提供有價值的資訊供大家參考。同時，我們也希望能夠將熱點事件、新的產品特性及其他有價值的資訊聚集起來，為您提供具有前瞻性的支援資訊，保持對於當前最新的資料庫新聞和事件的了解，其中包括重要資料庫產品發布、警報、更新、新版本、修補程式等，以及對國產資料庫的一些突出能力的總結。

此文檔原本是我們為重要客戶整理的經典案例，現限時開放下載，希望可以幫助到讀者朋友們。

目錄

  • 新聞：2020年2月資料庫流行度排行
  • 聚焦：深入解析 | Oracle Database 20c 十大新特性一覽
  • 聚焦：Oracle Database 20c ：雲上資料庫創建步驟指南搶鮮預覽
  • 經驗：MySQL故障分析之Abort Connection
  • 經驗：探索記憶體問題如何造成資料庫性能嚴重異常
  • 問題：機房掉電LostWrite強制啟庫
  • 問題：核心資料庫一波三折異常重啟分析
  • 警示：Oracle 18及19c Merge into因bug觸發ORA-30081
  • 警示：Oracle 11g部分版本因bug導致宕機
  • 總結：高斯資料庫運維應知應會
  • 公告：資料庫「每日一題」新功能上線！

本文出自《雲和恩墨技術通訊-2020.02》，原文：https://www.modb.pro/doc/2249（複製到瀏覽器中打開或者點擊左下角「閱讀原文」）

另：在「數據和雲"公眾號後台回復「雲和恩墨技術通訊」即可查看並下載往期技術通訊集錦。

問題：核心資料庫一波三折異常重啟分析——桑凱

資料庫異常重啟的原因多種多樣，但總的來說不外乎以下原因：存儲、網路、作業系統或者資料庫本身以及bug等等。當我們面對這類故障時，細緻入微的排查顯得格外重要，尤其是當提SR之後無法準確定位問題時，那我們是否就繳械投降了呢？答案是否定的。本文分享一起客戶近期資料庫異常重啟，且提SR依然未解決的案例，在此分享給大家。

問題描述

某客戶核心資料庫第二節點在2019年12月21日3:06出現實例重啟。該資料庫第一節點在2020年1月29日2:06又一次出現實例重啟。

問題分析

1.查看alert和trc日誌

通過查看資料庫故障時間段的alert和trc日誌發現從資料庫在2019-12-21 03:06:32出現600錯誤：

隨後在03:06:42實例2被LMS進程terminate。

通過該Alert日誌中「ORA-00600: internal error code, arguments: [kjbmpsch:rcvrd], [174],[1], [], [], [], [], [], [], [], [], []」錯誤函數和對應的TRC文件stack資訊，在Oracle MOS中找到如下BUG資訊，但是「 kjbmpsch:rcvrd 」相關的BUG在 12.1.0.1時已經修復，而我們資料庫目前的版本為12.1.0.2版本，與BUG環境並不匹配。

經過進一步深入排查發現該AlertLog的LMS0的進程號(7079142)和做Cdump時顯示的OSID(46662761)並不對應，該問題通過SR諮詢Oracle官方，官方也未給出明確原因，僅要求升級到更高版本。

通過查看2020-01-29的日誌分析：資料庫在2020-01-29 02:06:19出現ORA-00600錯誤：ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2],[0x1268357A8], [0x1268368F8], [384], [], [], [], [], [], [], [], []。

通過我司對該ORA-00600錯誤函數和對應的TRC文件的stack資訊，進行深入分析，在Oracle一篇關於AIX作業系統中LMS Crash with ORA-00600 [kjctr_pbmsg:badbmsg2] 和 ORA-29770報錯的文檔中匹配到了對應的報錯函數和stack trace。

ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2], [0x1268357A8], [0x1268368F8], [384], [], [], [], [], [], [], [], []2020-01-29 02:06:19.643840 :kjzduptcctx(): Notifying DIAG for crash event—– Abridged Call Stack Trace —–ksedsts()+244<-kjzdssdmp()+236<-kjzduptcctx()+512<-kjzdicrshnfy()+1008<-ksuitm()+6136<-ksbrdp()+6144<-opirip()+1540<-opidrv()+1124<-sou2o()+240<-opimai_real()+292<-ssthrdmain()+452<-main()+208<-__start()+112

明確指出該問題是由於LMS進程由於不明的原因接受到一個巨大包或者損壞包，該問題間歇性發生，導致實例崩潰，數據包的損壞發生在作業系統或者網路層。

2.網路層分析

由於LMS進程主要負責私有網路的數據傳輸，對核心資料庫雙機的私有網路進行了比較細緻的排查。

OSW數據分析：通過分析OSW每15秒採集的網路數據，可以看到在2019年12月21日03:06:27採集到第二節點的主機UDP資訊中bad data length fields累計數值為5，而到了03:06:43該累加值變為77。期間剛好經歷了實例重啟。第一節點該指標並未變化。

zzz ***Sat Dec 21 03:06:27 CST 2019udp: 1941579855 datagrams received 0 incomplete headers 5 bad data length fields 0 bad checksums 17260917 dropped due to no socket 13170454 broadcast/multicast datagrams dropped due to no socket 20771 socket buffer overflows 1911127708 delivered 499362874 datagrams outputzzz ***Sat Dec 21 03:06:43 CST 2019udp: 1941734652 datagrams received 0 incomplete headers 77 bad data length fields 0 bad checksums 17262013 dropped due to no socket 13170454 broadcast/multicast datagrams dropped due to no socket 20771 socket buffer overflows 1911281337 delivered 499390230 datagrams output

該指標顯示出UDP數據包在傳輸過程中出現錯誤數據長度，數據包在傳輸中存在錯包。

在2020-01-29 02:06OSW採集的網路統計數據中同樣可以看到fragments dropped在資料庫宕機前後出現跳變，該指標代表網路中存在丟包。在一個良好的網路中，該統計值應為0。

在參考Oracle兩篇關於RAC性能和問題診斷的問題分析的文檔，「Troubleshooting gc blocklost and Poor Network Performance in a RAC Environment (Doc ID 563566.1)」和「如何診斷RAC系統中的'gc cr multi block request'?(Community Discussion ID 3358223)」中指出網路指標中bad datalength等指標增長會導致RAC的性能問題。

網路拓撲：在經過對當前基礎網路的調研後發現，目前私有網路的拓撲和官方推薦的配置有較大的差距。目前該資料庫私有網路和業務網路共用VLAN和交換機方式，在Oracle Doc ID 563566.1文章中明確指出，業務網路和私有網路交換機的共用會導致應用性能下降、網路堵塞、global cache block loss等問題，文章中更進一步指出，RAC的業務網和私網應該使用獨立的VLAN並且定義在non-routed子網。私有網路交換機應該是獨立的，不應該從業務網路的接入交換機進行私網連接，如果使用了VLANs，那麼每套數據的私網的VLAN應該是獨立的。

通過Oracle CVU安裝環境預檢查工具進一步排查，發現該資料庫私網的多播地址某a網段測試失敗：

Oracle安裝的先決條件是需要該檢測兩組IP均成功。經過和網路組人員了解該系統使用的xx交換機，該型號交換機如果需要開啟某a網段多播地址通訊需要進行更多的配置。

3.系統參數

通過檢查數據主機的參數發現兩台主機的私網網卡的MTU值採用的是默認1500,該值過小會導致私網反覆將需要傳輸的數據包拆開傳輸，如果連接私網的網路設備能夠支援Jumbo Frames，建議開啟Jumbo Frames，將MTU調大。這樣可以極大提升私網網路的性能。

4.資料庫相關業務分析

核心資料庫曾在2018年11月18日星期日02:21，2018年12月8日星期六05:23出現LMS進程異常導致的資料庫實例中斷，從2018和近兩次次故障時間點的共性可以看出每次出現該故障均為周末，並且都發生在夜間批處理期間，資料庫業務繁忙，此時LMS進程的負載就會加重，會更容易發生該問題。

綜上分析，通過宕庫時的日誌資訊提供的線索，我們也查閱Oracle內部的大量BUG均未找到和本次故障相匹配的BUG，在發送SR請求Oracle協助分析過程中，Oracle方面也並未給出相關的BUG，所以該問題如果從BUG方向考慮則可能是由於Oracle一些未公開的BUG導致。

另一方面如果該問題並不是由於BUG導致，而是由於某些配置錯誤或者基礎環境問題觸發了Oracle的異常處理機制，進而出現ORA-00600的錯誤。我們通過一篇Oracle有關UDP私網傳輸出現壞包所產生的相關ORA-00600錯誤在下表可以看到。2018年的兩次和近兩次宕庫的報錯函數均有匹配，分別為：kjctr_pbmsg:badbmsg2、kjctr_pbmsg:badseq和kjbmpsch:rcvrd。

ORA-00600: internal error code, arguments: [kjbmpocr:spkey], [0], [2363548],ORA-00600: internal error code, arguments: [kjctr_rksxp:validate], [], [],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badseq], [8], [21],ORA-00600: internal error code, arguments: [corrupt_mh], [0x7FBB8B45EF08],ORA-00600: internal error code, arguments: [kjctr_rksxp: Nested receive], [],ORA-00600: internal error code, arguments: [ksxpmcpy1], [], [], [], [], [],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2],ORA-00600: internal error code, arguments: [kjdrisRMnovalid:!creating_pt],ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg],ORA-00600: internal error code, arguments: [kjbmpsch:rcvrd], [194], [4], [],ORA-00600: internal error code, arguments: [kjctr_rksxp:rcvr], [136], [2],

通過我們對現場網路基礎環境的排查發現了，資料庫私網和業務網交換機共享，私網VLAN未做隔離，私網多播某a網段IP不通，OSW收集udp網路數據存在壞包。並且三次故障均在資料庫有大量負載情況下發生，因此我們有理由認為問題極有可能是由於和網路相關的拓撲和配置未按照Oracle標準，導致私網網路數據包傳出出現無法糾正錯誤導致。

問題解決

針對此次故障後分析後我們提出以下建議：

1)對於業務量較大的時間段，考慮停止統計資訊收集、停止備份，減少資料庫的壓力，規避部分由於業務壓力導致觸發該問題的可能。

2)調整網路拓撲結構，對於xx交換機的某a網段多播關閉進行調整。

3)通過AIX: LMS Crashwith ORA-00600 [kjctr_pbmsg:badbmsg2] or ORA-29770 (Doc ID 2509185.1)文章給出的兩種通過參數調整的解決方案，兩個方案參數的調整需要關閉集群內所有資料庫。

a.可以通過設置以下參數減少LMS數據包的大小到1500位元組以下。

_lm_send_queue_batching=FALSE_lm_process_batching=FALSE_side_channel_batch_size=57

b.假如私網連接的網路設備支援Jumbo Frames，調整資料庫私網的MTU值到9000。

VirMach 便宜 VPS

QNews

QNews