前言
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 或者查
用下面的語句查：
都是不準的
作者：Owen Zeng
出處：https://www.cnblogs.com/OwenZeng/
如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”将是我最大的寫作動力！歡迎各位轉載，轉載文章之後必須在文章頁面明顯位置給出作者和原文連接配接，否則保留追究法律責任的權利。