前言
很多時候數據庫的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/
如有轉載請保留原文地址!
----------------------------------------------------------------------------------------------------
總結
問題的結果往往比較簡單，也相對容易解決,但綜合各項指標深入分析問題原因是值得和每一個技術人員探討的，這也是爲什麼用一篇長案例來分析一個小點的原因。
再思考：本案例中服務器的架構設計是比較完善的，已經做了讀寫分離可以輕鬆的把這樣的大操作指向輔助服務器，並且可以做到負載均衡，那麼如果你的單機服務器也有類似這樣一個報表操作，你會怎麼辦呢？
----------------------------------------------------------------------------------------------------
原創鏈接：http://www.cnblogs.com/double-K/archive/2016/06/02/5538249.html