我的 templog.ldf 很大（45gb），如果我該怎麼辦？
我安裝了 SQL 2005，並且我的 templog.ldf 文件不斷增長，以消耗它所在驅動器上的所有可用空間。有時它會在幾 mb 空閒時停止，但有時它會更進一步，這是 c 驅動器，我認為這種行為可能與我看到的其他一些問題有關。
我的問題是，我應該怎麼做，我可以將日誌移動到另一個驅動器，但我有理由假設它不會在那裡做同樣的事情。我假設這種行為可能是我可以更改的結果，並且 45gb 對於 tempdb 日誌來說是一個不尋常的大小。我們在程式碼中確實使用了很多臨時表和表值函式，因此使用 tempdb 的空間很大，我可以理解 tempdb 數據庫的增長，但不明白 templog 增長的原因。
到目前為止，我已經執行了 DBCC OPENTRAN(’tempdb’) 來查看是否有任何舊事務在附近，它們不是。我已經閱讀了有關如何縮小 tempdb 並且已經這樣做了幾次，但我真的想知道如果我能做些什麼來阻止這種情況的發生，或者更多關於它為什麼會增長如此之多的細節第一名。
==編輯==
1) tempdb 使用簡單的恢復模型
2) templog 的增長發生在早上幾個小時內，當時我們有一些預定的查詢正在執行，基本上是前一天辦公時間以外的報告負載。文件的大小在這段時間內穩步增長。我們控制同時執行多少並發報告，增加並發報告的數量會增加日誌的增長速度。
檢查您的報告查詢。你有什麼有區別的嗎？他們中的任何一個都有笛卡爾連接嗎？
是否有任何報告查詢以聯接成員的身份訪問連結伺服器？如果是這樣，這可能會導致 tempdb 日誌和數據庫增長。
當報告在早上執行時，它們中的任何一個都會崩潰嗎？
在向 Microsoft 提出 PSS 電話並深入調查該問題後，我們遇到了類似的問題，我們將其劃分為以下可能的原因和解決方案。
原因：
出現這些症狀的可能原因是放置使用者數據庫的磁碟/lun 存在嚴重的 I/O 響應問題；這會導致使用者數據庫上的自動檢查點需要很長時間才能完成。
現在，tempdb 上的檢查點僅在 tempdb 日誌已滿 70% 時才會出現，並且它的優先級低於使用者數據庫檢查點。因此，當使用者數據庫上的自動檢查點發出並試圖完成時，由於 tempdb 的大量使用導致 tempdb 日誌文件快速填滿；在 70% 的日誌使用率時，臨時數據庫檢查點出現，但在使用者數據庫檢查點之後排隊。
在使用者數據庫檢查點完成的時間內，tempdb 日誌文件不斷被填滿，如果設置了 autogrow，則日誌文件在需要更多空間時會增長。這就是日誌文件不斷增長的原因。
總之，您描述的症狀最可能的根本原因是由於您的使用者和/或 tempdb 數據庫/日誌文件的磁碟/lun 的 I/O 響應不佳。
解決方案：
我們在整理 I/O 子系統時解決了這個問題，方法是設置一個警報，該警報在 tempdb 日誌文件已滿 75% 時觸發，並作為響應執行一項強製手動“檢查點”（優先於自動系統）的作業檢查點），清除 tempdb 日誌以防止它無限期地自動增長。將日誌文件保留為自動增長以應對任何其他可能性仍然是一個好主意。此外，我強烈建議您在安裝修復程序後考慮根據您的環境將 tempdb 日誌文件的大小減小到有意義的大小。
希望這可以幫助。