TempDB暴漲問題排查

前言

tempdb日誌文件暴增 ，造成磁盤空間不足，甚至影響業務運行。如何找到產生問題的元兇，加以解決避免以後再次發生。

正文

如圖，tempdb log文件從7.40開始突然暴漲，因爲 tempdb 0 M到 40G

tempdb 所在磁盤是C 盤

C盤的可用空間正好也爲40G

在下午16.22左右的時候tempdb 文件暴漲已經影響到業務使用.臨時解決是備份收縮日誌。下面通過監控信息查找造成問題的原因：

查看7.40 之後這段時間 的運行語句，發下有個會話1085一直在運行

這個會話分配了內部對象（就是使用了tempdb的對象）

而言會話從7.46開始，一直持續到下午16.20 從時間上也非常吻合。所以他就是我們要找的元兇。

原因

對應普通的 簡單模式的數據庫無法重用日誌的主要原因是沒有做checkpoint，和存在沒有提交的事務。但對於TEMPDB 來講 他不需要預寫日誌。因爲Tempdb 不支持重做(Redo)但需支持回滾(rollback).這也是tempdb日誌存在的原因.

如果一個事務還沒有提交，那它可以在任何時候回滾。SQL Server必須做好這種準備，以便能夠從日誌記錄中找回修改前的數據內容，完成回滾。在SQL Server裏面，所有的日誌記錄都有嚴格順序，中間不可以有任何跳躍。所以如果某個數據庫有沒有提交的事務，SQL Server會標記所有從這個事務開始的日誌記錄（不管和這個事務有沒有關係）爲活動事務日誌 。這些日誌記錄都有可能「需要」被用來做回滾。

解決

找到語句後，從之前的截圖的等待信息可以看出，這個語句一直持續運行的原因是，等待ASYNC_NETWORK_IO

這說明，客戶端和數據庫服務器網絡傳輸存在問題或者程序中未接收數據庫傳輸的數據。更多的是後者。問題就提交給開發，檢查代碼，對程序進行優化。

補充

查看日誌空間使用的方法：

DBCC LOGinfo() 查看vlf的狀態

DBCC SQLPERF(LOGSPACE) 建議用，查看日誌空間的使用 ，更準。

從UI 或者查

都是不準的