本篇文章寫在新春佳節前夕，也是給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億！
紀念一下
--------------部落格位址---------------------------------------------------------------------------------------
部落格位址 http://www.cnblogs.com/double-K/
歡迎轉載，請注明出處，謝謝！
-----------------------------------------------------------------------------------------------------
系統運維就是保證系統平穩運作的工作，看似簡單但個中奧妙和心酸隻有運維人才能體會，不要放過每一個細節，一個簡單突發情況處理可能引出一系列問題，而解決這些問題又是保證系統平穩運作基礎，請給運維人多一些關愛吧，比如春節來個大紅包，哇哈哈哈哈！！
有的小夥伴已經開始春節休假了，祝大家新春快樂，系統平安！
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！