SQL Server 2005 日誌截斷 - 60Gb 日誌需要多長時間；分鐘、小時還是天？
我接管了一個舊網站。長話短說，託管電腦的人，備份所有數據庫文件，但沒有針對備份的維護計劃（例如，他們實際上是從磁碟備份文件，因此不會發生截斷）。
恢復模式為FULL (SQL Server 2005)。
這有點像“一根繩子有多長”的問題，但只需要一個大致的數字就可以知道截斷需要多長時間：
BACKUP LOG databasename WITH TRUNCATE_ONLY60Gb 日誌可能是幾分鐘、幾小時或幾天（機器是合理的英特爾 4 核 2.5Ghz 8Gb 機器（不是 SSD 驅動器））？
但是沒有針對備份的維護計劃（例如，他們實際上是從磁碟備份文件，因此不會發生截斷）。恢復模式為 FULL (SQL Server 2005)。
我猜以前的使用者正在進行文件系統備份，在我看來，當您執行重要的應用程序時，這不是最佳做法。您永遠無法獲得時間點恢復。您對創建維護計劃備份的想法是正確的，它可以讓您更好地控製備份。另外，如果您不想要時間點恢復，您可以將數據庫置於簡單恢復模式，並且可以根據 RPO 和 RTO 進行完整備份和差異備份。這樣可以避免事務日誌文件備份的麻煩和日誌文件的不必要增長
這有點像“一根繩子有多長”的問題，但實際上只需要一個大致的數字來說明截斷需要多長時間。60Gb 日誌可能是幾分鐘、幾小時或幾天（機器是合理的英特爾 4 核 2.5Ghz 8Gb 機器（不是 SSD 驅動器））？
首先請注意日誌截斷和事務日誌備份不是一回事。它的事務日誌備份只負責完全恢復模式下的日誌截斷。對於處於簡單恢復模式的數據庫，檢查點會導致日誌截斷或日誌增長到其大小的 70%。
關於 60 GB 日誌文件的事務日誌備份需要多少時間很難預測，沒有這樣的公式。如果您有更快的日誌文件所在的磁碟和更快的磁碟來轉儲備份，則需要正常時間。備份從磁碟讀取數據並將其寫入磁碟，因此如果磁碟沒有面臨 I/O 爭用，它會很快。
您還必須閱讀