日誌文件管理 - 磁碟空間
在我們的組織中，我們有幾個非生產環境，在這些環境中，開發人員可以自由地使用 TSQL 程式碼和數據庫執行。DBA 團隊通常不會監控或維護它們。最近，一些使用一台伺服器的開發人員不得不編寫大量程式碼的程序，使得他們的日誌文件增長到 10-20GB（在大約 15-40GB 的數據庫上），直到他們用完我們提供的驅動器卷上的空間。日誌文件。數據庫都處於簡單恢復模式，並且（幾乎）從未進行過備份。
作為一個創可貼，我創建了一個 SQL 代理作業，任何人都可以執行它來縮小伺服器上的所有使用者日誌文件。
可以使用哪些有效的日誌文件管理策略？
例如，我的理解是，由於使用者通常會進行大量密集工作，因此檢查點可能會被限制，因此發布手動檢查點不會有任何優勢。是這種情況還是我們實際上應該調查在他們的程式碼中添加手動檢查點？
為了清楚起見，我們感興趣的是磁碟上的日誌文件空間，而不是日誌文件中的空間。
由於您的數據庫處於簡單恢復模式，檢查點將由數據庫引擎自動處理或當日誌文件增長到其大小的 70% 時，您也可以提供手動檢查點。但是一個長時間執行的事務仍然可以持有日誌，並且即使您手動提供檢查點也不允許它截斷。
在您的情況下，無法進行日誌備份，因為恢復模式很簡單。
您可以使用批量記錄恢復模式來利用支持的批量記錄功能。但非最低限度記錄的事務將完全記錄在批量記錄恢復模式中，所以要小心。由於您不關心時間點恢復，您可以根據需要在完整和批量記錄之間切換恢復模式。
http://technet.microsoft.com/en-us/library/ms191244(v=sql.105).aspx
如果您的團隊正在執行生成大量日誌的巨大 DML，那麼您會要求他們將 DML 分成塊來破壞以避免填充日誌。巨表的索引重建也會產生海量的日誌。
使用 truncate table 從表中刪除記錄（如果您想刪除完整的記錄），因為與刪除相比，它被輕微記錄，但如果表具有外鍵約束和 Indentity，則不要使用。 http://msdn.microsoft.com/en-us/library/ms177570.aspx
以上幾點肯定會給您帶來大量伐木的緩解。
希望這可以幫助
您使用的是長期執行的事務。他們需要更多的驅動器空間來儲存事務日誌。故事結局。