前言 tempdb暴增，造成磁碟空間不足，甚至影響業務運行。 正文 如圖，tempdb log文件從7.40開始突然暴漲，因為 tempdb 0 M到 40G tempdb 所在磁碟是C 盤 C盤的可用空間正好也為40G 在下午16.22左右的時候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 或者查
用下麵的語句查：
都是不准的
