前言

　　很多時候資料庫的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/

如有轉載請保留原文地址! 

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

 總結

　　問題的結果往往比較簡單，也相對容易解決,但綜合各項指標深入分析問題原因是值得和每一個技術人員探討的，這也是為什麼用一篇長案例來分析一個小點的原因。

　　再思考：本案例中伺服器的架構設計是比較完善的，已經做了讀寫分離可以輕鬆的把這樣的大操作指向輔助伺服器，並且可以做到負載均衡，那麼如果你的單機伺服器也有類似這樣一個報表操作，你會怎麼辦呢？

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

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