最小化執行簡單恢復模型的開發人員機器上的 SQL 事務日誌文件大小

我們在開發環境中有很多 SQL 伺服器，我們從不備份數據庫（程式碼的 TFS 就足夠了）。

(SharePoint) 數據庫都設置為簡單恢復模式，但是日誌文件，尤其是 SharePoint 配置數據庫的日誌文件變得非常大，並填滿了我們在 SQL 伺服器上的數據驅動器。

由於這些日誌文件從未用於任何事情，我想就如何最好地最小化這些日誌文件的大小提出建議 - 或者如果可能的話甚至禁用它們。

我不完全確定為什麼即使在簡單的日誌記錄中日誌文件也會變得如此之大（檢查了長時間執行的事務（DBCC OPENTRAN）但沒有發現）。

我猜日誌文件沒有被截斷的原因是，我們沒有進行任何備份，因此沒有達到檢查點。

日誌文件的自動增長設置為自動增長 10%，限制為 2 GB，所以我想這就是為什麼這裡也沒有達到檢查點（70%）的原因。

在不犧牲性能（例如 VLF 碎片）的情況下保持日誌文件較小（最佳情況 0）的最佳策略是什麼？

您是否正在執行任何可能進行任何重新索引或其他繁重工作的維護工作？即使使用簡單的恢復，日誌也需要至少足夠大以保存針對數據庫發出的最大事務。嘗試執行 DBCC SQLPERF(LOGSPACE) 並檢查實際使用了多少日誌文件。如果它非常低，那麼簡單的恢復可能會按預期工作，並且日誌文件可能只會增長，因為它需要那麼大才能支持一些大於平均水平的事務。

引用自：https://serverfault.com/questions/239627