備份 MS SQL Server 數據庫會創建一個巨大的事務日誌

我正在託管一個包含大約 100 個數據庫的 SQL Server 2012 數據庫伺服器。我使用標準維護計劃每天備份所有使用者數據庫，並每小時備份一次事務日誌。

一個大約 80 MB 的數據庫在早上 6 點可以正常備份，但以下事務日誌通常為 1-2 GB。我已經檢查過，事務日誌在完整備份中被正確截斷，但它在備份後立即填滿。我嘗試切換到簡單恢復，縮小事務日誌文件，然後重新啟用完全恢復。一切正常，.log 文件減小到 4-5 MB。然而，在一天之內，它已經達到了 2 GB——其中大部分似乎發生在我執行完整備份時。該日誌已達到 10 GB，即使它每天都會被截斷。

只能通過單個 Web 應用程序訪問數據庫，在事務日誌膨脹期間，該應用程序似乎沒有任何內容訪問數據庫。

我試圖查詢事務日誌本身，但看不到任何明顯的東西。

備份 80 MB 的數據庫如何創建 2 GB 的事務日誌？如何找出日誌中實際包含的數據並確定它的來源？

語句“事務日誌在完整備份上被正確截斷，但在備份後立即填滿”不是備份的操作方式。所有事務日誌截斷都在完整備份後的第一個事務日誌備份期間完成，截斷被推遲到完整備份完成。

完整備份期間事務日誌備份會發生什麼情況？

如果您在完整備份之後但在第一次事務日誌備份之前看到更大的事務日誌，這通常是設計使然。但是，如果您說在完整備份期間幾乎沒有任何活動會導致大量活動，那麼我會立即開始查看您的工作。通常，重新索引會導致大量日誌記錄，但如果這是主要的罪魁禍首，那就太奇怪了。仔細監控在此期間發生的情況並執行相同的查詢。隨意描述在那段時間發生的事情，因為這可能是一個複雜的問題。

您的標準維護計劃是否也重建所有索引？這會生成大量事務日誌寫入。我會：

• 從https://ola.hallengren.com/下載 Ola Hallengren 維護解決方案
• 使用該解決方案執行智能索引維護（它僅基於碎片門檻值而不是所有索引重建索引）。
• 確定數據庫的恢復點目標 (RPO) 和恢復時間目標 (RTO)。
• 使用 Ola Hallengren 維護解決方案進行完整備份和日誌備份，以滿足您的 RPO 和 RTO。
• 定期備份事務日誌可以防止事務日誌失控。
• 記錄並測試災難恢復計劃，以確保您能夠在發生災難時及時恢復完整備份和事務日誌備份。

引用自：https://dba.stackexchange.com/questions/153794