在 SQL Server 2005 中限制臨時日誌的大小可以嗎？
我正在調查一個問題，我的 tempdb 日誌文件與任何看起來合理的東西都不成比例。今天早上它是數據文件大小的 10 倍以上。但是，數據庫繼續正常執行，臨時日誌大小的唯一限制似乎是它所在的磁碟大小。
那麼我的問題是，限制 templog 的大小對我來說是否安全，我聽說你不應該限制 tempdb 的大小，因為它對於需要在 sql server 中完成的工作至關重要。但是，日誌文件增長到磁碟允許的大小的事實表明我可以在不破壞任何內容的情況下限制它。是這樣嗎？如果是這樣，是否有一個下限（即數據文件的組合大小）我不應該限制在下面？
順便說一句，我意識到這不是解決日誌增長問題的解決方案，正在調查但可能不會很快解決。
乾杯，
通過限制日誌的大小，您要做的就是在日誌增長達到限制時導致失敗。（將出錯並可能回滾事務）。
實際上，這可能是一種查看日誌增長如此之大的有用方法！:) 儘管更好的方法是使用 Perfmon 來監視 SQL:Database:Log Used (kb) 計數器，以查看它何時增長，並將其與伺服器上的其他活動相關聯。
在向 Microsoft 提出 PSS 電話並深入調查該問題後，我們遇到了類似的問題，我們將其劃分為以下可能的原因和解決方案。
原因：
出現這些症狀的可能原因是放置使用者數據庫的磁碟/lun 存在嚴重的 I/O 響應問題；這會導致使用者數據庫上的自動檢查點需要很長時間才能完成。
現在，tempdb 上的檢查點僅在 tempdb 日誌已滿 70% 時才會出現，並且它的優先級低於使用者數據庫檢查點。因此，當使用者數據庫上的自動檢查點發出並試圖完成時，由於 tempdb 的大量使用導致 tempdb 日誌文件快速填滿；在 70% 的日誌使用率時，臨時數據庫檢查點出現，但在使用者數據庫檢查點之後排隊。
在使用者數據庫檢查點完成的時間內，tempdb 日誌文件不斷被填滿，如果設置了 autogrow，則日誌文件在需要更多空間時會增長。這就是日誌文件不斷增長的原因。
總之，您描述的症狀最可能的根本原因是由於您的使用者和/或 tempdb 數據庫/日誌文件的磁碟/lun 的 I/O 響應不佳。
解決方案：
我們在整理 I/O 子系統時解決了這個問題，方法是設置一個警報，該警報在 tempdb 日誌文件已滿 75% 時觸發，並作為響應執行一項強製手動“檢查點”（優先於自動系統）的作業檢查點），清除 tempdb 日誌以防止它無限期地自動增長。將日誌文件保留為自動增長以應對任何其他可能性仍然是一個好主意。
希望這可以幫助。