資料庫實戰案例—————記一次TempDB暴增的問題排查
前言
很多時候資料庫的TempDB、日誌等檔案的暴增可能導致磁碟空間被佔滿，如果日常配置不到位，往往會導致資料庫故障，業務被迫中斷。
這種檔案暴增很難排查，經驗不足的一些運維人員可能更是無法排查具體原因，導致問題不能徹底解決。
場景描述
客戶系統比較穩定，用了5臺機器做了AlwaysOn高可用組，完全實現了讀寫分離。磁碟也做了規劃，主庫日常操作TempDB需求在20G以下，所以TempDB所在的磁碟只配置了100個G的空間。
本案例是客戶突然接到監控報警，顯示TempDB磁碟空間不足，可用空間不斷減小直到耗盡。
比較戲劇的是，這個客戶早上剛剛做了巡檢資料庫情況穩定，沒有什麼異常。
那麼我初步判定，這必然是一次特殊操作或應用配置出錯導致的問題。
深入指標分析
檔案看問題
TempDB暴增必然伴隨著檔案的增長，首先我們看一下TempDB檔案的增長情況。
可見TempDB的分配空間在14點50幾分的時候開始暴增，細心的朋友會發現這是1個G到6個G的增長，這是因為客戶的TempDB配置了16個數據檔案：
什麼造成了增長
造成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造成暴增的問題負主要責任，而且雪上加霜的是從會話的標識可以看出，這不是一個語句只一次的執行，而是在特定的時間存在比較大的併發操作導致。
與相關業務人員溝通，發現這是一個集團的類似報表的大消耗操作，因為對功能進行的調整，而程式人員的一次誤操作而錯誤的指向了叢集中的主庫，而導致的問題。
--------------部落格地址-----------------------------------------------------------------------------
如有轉載請保留原文地址!
----------------------------------------------------------------------------------------------------
總結
問題的結果往往比較簡單，也相對容易解決,但綜合各項指標深入分析問題原因是值得和每一個技術人員探討的，這也是為什麼用一篇長案例來分析一個小點的原因。
再思考：本案例中伺服器的架構設計是比較完善的，已經做了讀寫分離可以輕鬆的把這樣的大操作指向輔助伺服器，並且可以做到負載均衡，那麼如果你的單機伺服器也有類似這樣一個報表操作，你會怎麼辦呢？
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！