事務日誌增長非常快
我們的 SQL Server 2014 數據庫事務日誌之一增長得非常快，我找不到它的根本原因。
數據庫處於簡單恢復模式。在完全備份期間，日誌文件增長到其限制 (800GB)，備份失敗。
我在備份期間檢查了事務，沒有發現任何奇怪的東西。
所有事務都是我們的正常載入，沒有維護工作（索引重建等）
我知道備份會阻止日誌重複使用，但這意味著在備份期間會有 800GB 的變化，這沒有任何意義。
我將此數據庫與類似的數據庫大小、載入和備份持續時間進行了比較。第二個數據庫日誌的增長不超過 400GB。
數據庫大小為 7TB。備份時間為~20H。日誌增長的唯一時間是在備份期間。Log_reuse 顯示正確的 Backup_Restore。沒有長時間執行的事務。
問題在於日誌增長的“速度”——與具有相同負載和相同備份持續時間的類似站點相比，日誌減少了 4 倍。
在對數據庫進行完整備份時，SQL Server 無法在備份期間重複使用事務日誌，即使數據庫處於
SIMPLE恢復狀態也是如此。如果您的數據庫非常繁忙，或者備份需要很長時間，這可能需要大量事務日誌， 即使數據庫正在SIMPLE恢復中。為什麼 SQL Server 需要這樣做？
將數據庫想像成一個包含一組百科全書的書架，每個表都是該集合中的一本書。SQL Server 是圖書管理員。圖書管理員需要複製集合中的每一本書以獲得該集合的快照。
圖書管理員 (SQL Server) 開始在書架（數據庫）的一端複製書籍（表格），然後將其複製到遠端。*這需要時間。*如果賬簿中的數據正在發生變化（即數據庫事務），那麼獲得一致的（即 A C ID 中的“C”）快照將成為一項挑戰。
考慮這個時間表：
- 圖書管理員複印書 A。
- 圖書管理員複印 B 書。
- 書籍 A 和 Z 已更新。
- 圖書管理員複印書籍 C.
- 圖書管理員複製書 D。
- 書 C、X、Y、Z 已更新。
- 圖書管理員複製書籍 EZ。備份完成。
館員的備份不一致。它有一些舊數據（書籍 A 和 C，以及一些更新的數據（書籍 X、Y、Z）。為了使數據保持一致，圖書館員可以跟踪書籍 A 和 C 中的變化，然後在她的備份副本上前滾這些更改。
圖書館員有不一致的備份可能是可以的，但 SQL Server 有不一致的備份是不行的。SQL Server 的備份必須與單個時間點保持一致。
SQL Server 如何做到這一點？
當 SQL Server 開始備份數據頁時，它也開始通過事務日誌跟踪事務。在備份了最後一個數據頁之後，它還會備份數據備份期間發生的所有事務。恢復後，它將根據需要向前或向後滾動這些事務，以確保恢復一致的映像。
在 Simple Recovery 中備份繁忙的數據庫
根據 OP 的評論，有問題的數據庫是 7TB，需要 20 小時才能備份。這意味著該數據庫的事務日誌必須足夠大以容納 20 小時的事務。根據活動的數量和類型，所需的事務日誌量可能非常多。
要減少所需的事務日誌量，您可以嘗試加快備份速度，或在寫入活動減少期間進行備份，或兩者兼而有之。
根據您所說的，您的數據庫中可能存在長時間執行的 ransaction，並且在 tran 完成之前無法截斷日誌文件
您應該查詢
sys.databases以了解發生了什麼。SELECT name, log_reuse_wait, log_reuse_wait_desc FROM sys.databases;列
log_reuse_wait，並log_reuse_wait_desc會告訴你你需要知道的一切。以下是您將在那裡看到的內容的描述：
- 0 無
- 1 檢查點 等待檢查點發生。還行吧
- 2 日誌備份 您正在等待日誌備份發生。
- 3 主動備份或恢復。備份或恢復操作正在執行
- 4 活動事務 數據庫中有活動事務
- 5 數據庫鏡像 鏡像上有隊列，在主伺服器後面或鏡像由於某種原因暫停
- 6 複製 複製正在執行或數據庫“認為”它被標記為複制，或者如果您配置了複製，一切正常
- 7 數據庫快照創建
- 8 日誌掃描
- 9 AlwaysOn 可用性
如果您的問題是長時間執行的事務 - 您的選擇是找到它並找出它的用途，例如在Adam Machanic 的 WhoIsActive儲存過程的幫助下。
如果您正在處理數據庫“思考”複製，您可能應該重建您的日誌文件。
有關更多詳細資訊和可能的解決方案，請參閱下面提到的資源。
連結：