按計劃備份和截斷事務日誌的最佳方法
我不是 DBA，但事情就是這樣，我必須戴上 DBA 的帽子並在我的 SQL Server 實例上設置維護計劃。
所以一段時間以來，我一直讓我的 SSIS 通宵程序執行Execute SQL Task來執行備份 - 基本上是執行
master.dbo.xp_create_subdir以確保目標文件夾存在，然後BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.每當該任務失敗時，該過程的其餘部分將中止，並且我會收到通知，並在第二天早上註意到事務日誌的驅動器已滿載，因此我將手動截斷它們並繼續前進。 ..直到故事重演並且事務日誌再次超出可用磁碟空間。
“手動截斷”腳本如下所示：
use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go所以我越來越厭倦了，我決定嘗試正確地做事，並按照這裡的步驟創建一個實際的維護計劃：
問題是，我以前從未這樣做過，所以我有幾個問題：
- 像這樣備份事務日誌會自動截斷它們，還是我需要做其他事情？
- 可以同時執行數據和事務日誌備份嗎？如果沒有，那麼這樣做的正確方法是什麼？
- 備份文件被另一個程序在一夜之間獲取，該程序抓取伺服器上的所有文件並將它們儲存在其他地方 - 將備份集在 2 天后過期是個好主意嗎？我需要讓它們過期嗎？
- 清理任務分別刪除 .bak 和 .trn 子文件夾下的“舊”文件
G:\Backups。那有意義嗎？- 在 SSIS 中執行此操作會更好，因此如果/當備份失敗時我可以使 ETL 失敗？或者我的 ETL 過程是否應該關心？
抱歉，如果一篇文章的問題太多，如果需要，我會編輯並提出多個問題 - 我認為它們都是緊密相關的。
只有夜間 SSIS 正在寫入，白天都是讀取 - 我只需要每天恢復。
您應該根據您的業務需求選擇您的恢復模式：
- 有多少數據業務可以在鬆散的同時存活下來？
基於以上答案，您應該謹慎選擇您的數據庫恢復模式。
簡單來說*（不討論批量日誌恢復模型）*，
完整恢復模式允許日誌備份，允許時間點恢復。
- 當您進行事務日誌備份時可能會發生日誌截斷，即日誌文件空間將在每次日誌備份後重複使用並且不會膨脹！
簡單恢復模式僅允許您進行完整備份。時間點恢復是不可能的。
- 日誌截斷只能在檢查點發生（手動或自動）時發生，即由於您定期進行完整備份，您不必擔心事務日誌，因為 CHECKPOINT 將負責重用日誌文件的非活動部分。
*請記住，日誌截斷不是事務日誌文件大小的物理減小，*這意味著事務日誌文件的非活動部分被標記為可重用。
因此，您應該正確地調整您的事務日誌文件（和數據文件）的大小。增長日誌文件將引發自動增長事件（如果您的數據庫設置為自動增長作為最後的手段）。檢查我的答案 -自動增長 - 使用百分比？
我強烈建議您放棄維護計劃並實施
$$ a smart maintenance solution - that is easy, flexible and follows best practices $$- 5。- Ola 的備份解決方案（以及索引維護解決方案）。
讓我們解決您的問題：
像這樣備份事務日誌會自動截斷它們，還是我需要做其他事情？
請不要附加備份或將它們設置為過期。他們製造了一個大混亂。使用
INIT並使用帶有日期時間戳的單獨日誌備份。易於維護。為此，請使用 Ola 的備份解決方案。該解決方案也可以靈活地刪除舊備份。可以同時執行數據和事務日誌備份嗎？如果沒有，那麼這樣做的正確方法是什麼？
完整備份對 T-log 備份沒有影響。完整備份僅包含足夠的必要事務日誌，以便在還原事件中，數據庫可以在事務上與完整備份的數據讀取部分完成的時間保持一致。檢查 -完整備份包含多少事務日誌？
此外，完整備份期間的日誌備份不會截斷事務日誌。完整備份完成後的（幾個）日誌備份將截斷日誌。
備份文件被另一個程序在一夜之間獲取，該程序抓取伺服器上的所有文件並將它們儲存在其他地方 - 將備份集在 2 天后過期是個好主意嗎？我需要讓它們過期嗎？
清理任務分別刪除 G:\Backups 子文件夾下的“舊”.bak 和 .trn 文件。那有意義嗎？在 SSIS 中執行此操作會更好，因此如果/當備份失敗時我可以使 ETL 失敗？或者我的 ETL 過程是否應該關心？
對於以上兩者，請使用 Ola 的備份維護解決方案。它將負責刪除舊文件。