前言
很多時候資料庫的TempDB、日志等檔案的暴增可能導緻磁盤空間被占滿，如果日常配置不到位，往往會導緻資料庫故障，業務被迫中斷。
這種檔案暴增很難排查，經驗不足的一些運維人員可能更是無法排查具體原因，導緻問題不能徹底解決。
場景描述
客戶系統比較穩定，用了5台機器做了AlwaysOn高可用組，完全實作了讀寫分離。磁盤也做了規劃，主庫日常操作TempDB需求在20G以下，是以TempDB所在的磁盤隻配置了100個G的空間。
本案例是客戶突然接到監控報警，顯示TempDB磁盤空間不足，可用空間不斷減小直到耗盡。
比較戲劇的是，這個客戶早上剛剛做了巡檢資料庫情況穩定，沒有什麼異常。
那麼我初步判定，這必然是一次特殊操作或應用配置出錯導緻的問題。
深入名額分析
檔案看問題
TempDB暴增必然伴随着檔案的增長，首先我們看一下TempDB檔案的增長情況。
可見TempDB的配置設定空間在14點50幾分的時候開始暴增，細心的朋友會發現這是1個G到6個G的增長，這是因為客戶的TempDB配置了16個資料檔案：
注：為什麼配置這麼多TempDB檔案請參見：Expert 診斷優化系列------------------給TempDB 降溫
什麼造成了增長
造成TempDB暴增原因很多語句使用臨時表、語句排序、CheckDB等，但這些都是可以在語句中反應出來。是以下面我們分析一下語句。
注：很多使用過SQL專家雲平台或工具的朋友可能不會注意裡面一些細節，其實很多細節（如上面的TempDB檔案增長趨勢和下面的語句配置設定空間）的設計都是解決一些疑難的問題。
首先語句中的其中兩個名額使用者配置設定空間（MB）和内部對象配置設定空間（MB）指的就是對TempDB的使用消耗。
注：使用者配置設定空間可能是臨時表使用的比較多，内部對象配置設定空間可能是排序或者hash join等操作（其他使用的消耗可以參見前面給出的連結文章）
配置設定空間越大，也就說明語句越消耗TempDB資源。
我們有兩種方式找到到底是什麼操作導緻的TempDB暴增，可以直接找時間點的語句，也可以在TempDB資源消耗的高到低順序中找！
為了全面了解一下TempDB的問題，這裡我們采用第二種方式。
那麼我們就分析一下語句對TempDB資源被消耗的情況：
步驟1：首先我們按照使用者對象配置設定空間排序：
經過排查，這裡面使用者空間配置設定比較高的都是CDC的作業，伺服器上确實運作這幾個庫的CDC作業。其他的一些操作的使用者配置設定空間都比較小，是以這不是造成問題的原因！
步驟2：接着我們按照内部對象配置設定空間排序：
這裡發現最消耗空間的是CheckDB的操作，但時間點是對應不上的，是以這也不是問題的原因。
繼續排查：
在消耗排位在第三的這個語句中我們發現了等待資源FGCB_ADD_REMOVE（這個可以簡單了解為有大量的檔案自動生長發生，這裡是16個TempDB檔案），并且使用的内部對象空間也很高，并且我們還發現有多個會話同時執行這樣的高消耗操作。
繼續深入：
性能計數器的表象也與之前的種種迹象相吻合。
排查結論
綜合各項現象名額，可以分析出系統在下午14點57分左後開始執行TempDB高消耗操作，語句本身是一個近千行涉及大量表連接配接排序等操作的複雜存儲過程，對TempDB造成暴增的問題負主要責任，而且雪上加霜的是從會話的辨別可以看出，這不是一個語句隻一次的執行，而是在特定的時間存在比較大的并發操作導緻。
與相關業務人員溝通，發現這是一個集團的類似報表的大消耗操作，因為對功能進行的調整，而程式人員的一次誤操作而錯誤的指向了叢集中的主庫，而導緻的問題。
--------------部落格位址-----------------------------------------------------------------------------
原文位址: http://www.cnblogs.com/double-K/
如有轉載請保留原文位址!
----------------------------------------------------------------------------------------------------
總結
問題的結果往往比較簡單，也相對容易解決,但綜合各項名額深入分析問題原因是值得和每一個技術人員探讨的，這也是為什麼用一篇長案例來分析一個小點的原因。
再思考：本案例中伺服器的架構設計是比較完善的，已經做了讀寫分離可以輕松的把這樣的大操作指向輔助伺服器，并且可以做到負載均衡，那麼如果你的單機伺服器也有類似這樣一個報表操作，你會怎麼辦呢？
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！