前言

　　本篇文章寫在新春佳節前夕，也是給IT運維朋友一個警醒，在春節長假前請妥善體檢自己的系統安心過個年。

　　千里之堤毀於蟻穴，一條看似簡單的語句就能拖垮整個系統，您的SQL Server很久沒體檢了吧？ 就像一塊藏著刀片的蛋糕！怎能安度春節？

　　日誌暴增的問題處理過很多，這只是很常規的一次，但是對於不是很熟練的運維兄弟，可能日誌暴增這樣的問題會被一帶而過，或者解釋成突發情況而不去處理，那麼隱患依然存在，在春節這樣的長假髮生可怎麼辦呢？

　　本文使用的工具：SQL專家雲平臺專業體檢工具 ：www.zhuancloud.com

場景描述

　　本案例是一個很成熟的ERP廠商的產品，接到使用者緊急電話，說他們日誌突然暴增磁碟告警，50G的資料庫日誌已經達到200G。

　　看到這有的看官可能會說，肯定是沒定時做日誌備份導致日誌不斷變大！或者說才200G 一點也不大呀！

　　沒錯，日誌不備份缺失會有這樣的問題，但這情景是小兒科，不會拿出來寫案例的，200G 確實也不大，但要分場景，在此客戶平均10個G 的場景下 200G已經是爆炸式的問題了！

　　為什麼會拿出來寫案例，就是因為想要告訴大家排查這樣問題的思路，不要讓這樣的暴增單純的說成突發情況！

問題分析

　　拿到收集檔案我直入主題，檢視日誌的增長情況、寫入狀態、問題時間點等資訊

　　在日誌的分配空間我們瞭解到日誌是在11點43分左右突然暴增一直增長到13點左右達到240G

　　分配空間也是同樣的情況在11點43分左右暴增，後期在1點半的下降就是日誌備份讓使用空間被釋放。

　　日誌檔案的寫入也符合這個時間點，在11點43分左右寫入達到40MB/秒，並且持續了1個多小時。

 　　通過這幾張圖，我們很清晰的就能定位到日誌暴增的時間點，下面只要找到對應時間點的語句即可！

　　我的排查思路有些不同，持續1個小時的寫入，必然伴隨著日誌檔案的增長（檔案增長設定固定值100MB），這裡需要提一下：這就是固定增長的好處，因為當達到240G 如果按照預設10%增長，那麼一次需要增24G 磁碟已經沒有那麼多空間，則會導致報錯，系統中斷！

　　回到排查思路，這裡我直接檢視對應時間點系統的等待情況：

　　直接找到日誌檔案增長的等待型別，檢視執行的語句確實執行時間是從11點15到13點15，和日誌增長的情況吻合！！

　　就這樣，只花了10分鐘就定位到問題，找到語句，由於儲存過程加密，我無法看到裡面的程式碼，但是暴增的語句已經找到，需要軟體廠商自行處理啦！！

　　就是這樣簡單，打完收工！所以不要放過這樣的問題排查！

後怕

　　為什麼說不能放過這樣問題的排查！！！

　　首先，這個系統正準備上叢集，叢集大家都知道單機變多臺，必然涉及到資料的同步，同步是要有消耗的，對寫入的效能會有影響，細心的小夥伴可能已經看到這個語句消耗了多少資源，邏輯讀，寫，影響行數有多少了

　　沒錯，64億的邏輯讀！為什麼會產生這麼大的日誌，導致暴增！因為寫入1億次，影響行數19億，並且執行的時間不是在夜間的維護期，而是在中午11點15開始，這麼大的處理在叢集方案部署的時候一定要高度警惕，這麼大的同步量完全可能導致叢集嚴重延遲，甚至宕機！所以這不單單是一次日誌暴增問題的排查了，也是對系統功能更加細緻的瞭解，如果這樣的問題沒有及早發現，就算集群后期測試也不一定會被測試到，進而導致叢集上線後的悲催。

PS:繼邏輯讀 23億，34億，45億後這個案例有重新整理了我見過的最大邏輯讀 64億！

　　紀念一下

--------------部落格地址---------------------------------------------------------------------------------------

 歡迎轉載，請註明出處，謝謝！

-----------------------------------------------------------------------------------------------------

總結

　　系統運維就是保證系統平穩執行的工作，看似簡單但箇中奧妙和心酸只有運維人才能體會，不要放過每一個細節，一個簡單突發情況處理可能引出一系列問題，而解決這些問題又是保證系統平穩執行基礎，請給運維人多一些關愛吧，比如春節來個大紅包，哇哈哈哈哈！！

　　有的小夥伴已經開始春節休假了，祝大家新春快樂，系統平安！

 ----------------------------------------------------------------------------------------------------

注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！