Sql服務器收縮事務日誌

Question

我每天在我的表上測試批量插入的正在進行的項目，批量文件每天大約有1200000條記錄。 事務日誌不斷增加。我忘記了一次9GB的事務日誌，還沒有備份。 像這樣收縮事務日誌是明智的做法。 可以在完整備份後收縮日誌，還是需要單獨備份日誌？ 感謝

Answer 1

這是莫大的聯繫，這是信息的摘要：

How do you clear the SQL Server transaction log?

你不想TRUNCATE_ONLY選項做

• 備份日誌有些東西然後SHRINKFILE。首先，這個TRUNCATE_ONLY選項已被棄用，並且在當前版本的SQL Server中不再可用。其次，如果您使用的是FULL恢復模式，則會破壞您的日誌鏈並需要新的完整備份。

• 分離數據庫，刪除日誌文件，並重新附加。我無法強調這可能會有多危險。你的數據庫可能不回來了，就可能出現爲可疑，你可能要恢復到一個備份（如果有的話），等等，等等

• 使用「收縮數據庫」選項。 DBCC SHRINKDATABASE和維護計劃選項來做同樣的事情是不好的想法，特別是如果你真的只需要解決日誌問題。定位您要調整的文件並使用DBCC SHRINKFILE或ALTER DATABASE ... MODIFY FILE（上面的示例）單獨進行調整。

• 將日誌文件縮小到1 MB。這看起來很誘人，因爲，嘿，SQL Server會讓我在某些情況下執行它，並查看它釋放的所有空間！除非數據庫是隻讀的（並且它應該使用ALTER DATABASE來標記），否則這絕對會導致許多不必要的增長事件，因爲日誌必須適應當前事務，而不管恢復模式如何。暫時釋放這個空間的意義是什麼？正如SQL Server能夠緩慢而痛苦地回收這些空間一樣？

• 創建第二個日誌文件。這將暫時緩解已經充滿磁盤的驅動器，但這就像試圖用創可貼修復被刺破的肺部。你應該直接處理有問題的日誌文件，而不是僅僅增加另一個潛在的問題。除了將某些事務日誌活動重定向到另一個驅動器之外，第二個日誌文件確實對您沒有任何幫助（與第二個數據文件不同），因爲一次只能使用其中一個文件。 Paul Randal also explains why multiple log files can bite you later。

How do you clear the SQL Server transaction log?

Answer 2

備份事務日誌（我假設數據庫處於完全恢復），然後收縮文件

DBCC SHRINKFILE (2, x) 

（x是一個以MB爲單位的目標大小）

確保留有一定的自由文件中的空間以避免自動增長。

如果沒有按預期工作，您也可以在收縮之前切換到簡單恢復，然後切換回完全。

如果日誌繼續增長，檢查

select log_reuse_wait_desc from sys.databases 

有問題的數據庫。