數據庫服務器主機重啟故障診斷分析

　　墨墨導讀：某客戶RAC數據庫服務器主機輪流發生集群與主機重啟，數據庫連接不上問題，如下為故障診斷思路。

　　一、故障現象

　　告警日志:

　　從數據庫告警日志可以發現，核心進程asmb 在2.9日15.06分 突然提示正在終止，隨后一節點數據庫報錯，不能與 ASM通信, 也就是連不上 ASM存儲,檢查ASM告警日志發現，核心進程ASMB 在2.9日15.06分 被kill 掉，隨后一節點的ASM實例掛掉，導致一節點數據庫也緊跟著掛掉

　　二、故障原因

　　從15:03開始

　　一節點開始報 voting file所在的磁盤，IO通信有超時的現象，磁盤hang住, 到15.05分開始 ocr_vote磁盤離線，一節點被剔出集群，

　　后續檢查主機，發現主機重啟過，檢查操作系統日志，發現從15.02分開始，: INFO: task ocssd.bin:16080 blocked for more than 120 seconds. 有任務被hung 住，

　　該錯誤是由于IO子系統的處理速度不夠快，不能在120秒將緩存中的數據全部寫入磁盤。IO系統響應緩慢，導致越來越多的請求堆積，最終IO 耗盡，系統內存全部被占用，導致系統失去響應，發生故障。

　　三、故障解決

　　建議一：

　　可以調整 操作系統參數，

　　vm.dirty_ratio=20

　　vm.dirty_background_ratio=3

　　目前操作系統配置文件/etc/sysctl.conf

　　中 沒有這兩個參數 ，建議調整，sysctl -p 生效，（調整該操作系統參數不用重啟主機）

　　vm.dirty_background_ratio 這個參數指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如5%）就會觸發pdflush/flush/kdmflush等后臺 回寫進程運行，將一定緩存的臟頁異步地刷入外存;

　　操作系統參數說明:

　　vm.dirty_ratio 這個參數則指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如10%），系統不得不開始處理緩存臟頁（因為此時臟頁數量已經比較多，為了避免數據丟失需要將一定臟頁刷入外存）；在此過程中很多應用進程可能會因為系統轉而處理文件IO而阻塞。

　　建議二：

　　另外在檢查中，發現該主機未配置大頁，建議配置大頁，可以極大提升數據庫性能

　　后期調整后至今沒有發現主機重啟，故障解決。

　　墨天輪原文鏈接：https://www.modb.pro/db/22702（復制到瀏覽器中打開或者點擊“閱讀原文”直達）

　　推薦閱讀：144頁！分享珍藏已久的數據庫技術年刊

　　數據和云

　　ID：OraNews

　　如有收獲，請劃至底部，點擊“在看”，謝謝！

　　點擊下圖查看更多 ↓

　　云和恩墨大講堂 | 一個分享交流的地方

　　長按，識別二維碼，加入萬人交流社群

　　請備注：云和恩墨大講堂 點個“在看”