SQL Server 2005 日志截断 - 60Gb 日志的长度；分钟、小时还是天？

Question

我接管了一个旧网站。长话短说，托管计算机的人备份所有数据库文件，但没有备份维护计划（例如，他们实际上是从磁盘备份文件，因此不会发生截断）。

恢复模式为FULL (SQL Server 2005)。

这有点像“一根绳子有多长”的问题，但只需要一个棒球场数字来说明截断需要多长时间：

BACKUP LOG  databasename  WITH TRUNCATE_ONLY

60Gb 日志（机器是合理的英特尔 4 核 2.5Ghz 8Gb 机器（不是 SSD 驱动器））可能需要几分钟、几小时或几天？

Answer 1

但是没有为备份制定维护计划（例如，他们实际上是从磁盘备份文件，因此不会发生截断）。恢复模式为 FULL (SQL Server 2005)。

我猜以前的用户正在备份文件系统，在我看来，当您运行重要的应用程序时，这不是最佳实践。您永远无法获得时间点恢复。您关于创建维护计划备份的想法是正确的，它可以让您更好地控制备份。另外，如果您不想要时间点恢复，您可以将数据库置于简单恢复模式，并且可以根据 RPO 和 RTO 进行完整和差异备份。这将避免事务日志文件备份的麻烦和日志文件的不必要增长

这有点像“一根绳子有多长”的问题，但只需要一个关于截断需要多长时间的棒球场数字。60Gb 日志（机器是合理的英特尔 4 核 2.5Ghz 8Gb 机器（不是 SSD 驱动器））可能需要几分钟、几小时或几天？

首先请注意日志截断和事务日志备份不是一回事。它的事务日志备份只负责完全恢复模式下的日志截断。对于简单恢复模式下的数据库，检查点会导致日志截断或日志增长到其大小的 70%。

关于 60 GB 日志文件的事务日志备份需要多长时间很难预测，没有这样的公式。如果您有更快的日志文件所在磁盘和更快的磁盘转储备份，则需要正常时间。备份从磁盘读取数据并将其写入磁盘，因此如果磁盘没有面临 I/O 争用，它会很快。

你还必须阅读

优化 SQL Server 中的备份和还原性能

了解 SQL Server 备份