上班時候遇到的問題，系統在進行某操作的時候報錯，按習慣查看數據庫錯誤日志發現是磁盤無法寫入，直接登錄數據庫服務器，果然C盤是被占滿了只有9M剩余，查找文件發現原因在於這個tempdb達到了21G。
當時有想到的方案是：
1、收縮數據庫，不知道時間多長不知道會有什么影響，放棄
2、清理日志，但日志清了也只有2G空間，清空的時間也不好說，說不定清完再飈上來，放棄
3、重啟服務，一般會初始化成幾M大小，但也有可能還是一樣大，而且不知道重啟后恢復會不會有問題，時間多長，會不會有其他什么影響，放棄；
4、重啟服務器，以前也有過宕機無法遠程所以重啟，采用后tempdb確實初始化了
重啟服務器無效的備用方案：把tempdb轉移到空間較大的分區（后來查了一下一樣也要停止服務來修改再啟動服務）
具體方法：檢查tempdb的邏輯名字和位置：
SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID('tempdb');
停止服務，記錄下數據庫文件的位置，然后打開目錄復制數據庫相關文件到新的位置，移動也可以，執行以下腳本：
USE master; GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'D:\tempdb\tempdb.mdf'); GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'D:\tempdb\templog.ldf'); GO
NAME = tempdev，NAME = templog 是邏輯名，FILENAME 指向的是數據庫文件的實際位置
最后檢查tempdb移動是否成功：
SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID('tempdb');
回頭會學習一下前3種操作方式的影響和如何確定tempdb增長的原因，再做記錄