缩小 SQL Server 日志文件对性能有何影响？

Question

我有一个 SQL Server 2008 数据库，它的数据文件大小约为 2GB，但日志文件超过 8GB。对于 2008 之前的数据库，我可以使用“备份日志”和该TRUNCATE_ONLY选项，但 2008 及更高版本的数据库不再提供此选项。

我确实有一个截断日志文件的脚本：

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

这会完全截断日志文件，但我的问题是：这会影响性能吗？

我每天执行两次完整备份，因此就数据前滚而言，日志实际上不是必需的。

Answer 1

我真的建议阅读Paul S. Randal 撰写的关于正确事务日志大小管理的重要性。

精髓是只有两种真正好的方法来处理事务日志：

1. 要么使用常规的 LOG 文件备份，LOG 文件将在每次 LOG 备份后重新使用它的空间，并且不会无限期地增长，或者

2. 使用 SIMPLE 恢复模型，您不必像执行常规完整备份一样关心 LOG 文件的大小。

与LOG 文件截断和性能相关的问题是，当要增加 LOG 文件时，您总是会受到性能影响（引自上述链接的博客文章）：

如果您缩小日志，那么它会再次增长 - 可能会导致 VLF 碎片化，并且肯定会导致您的工作负载在日志增长时暂停，因为日志无法使用即时初始化 [...]

更新：不要将 LOG 文件截断误认为是 DATA 文件缩小。数据文件缩小真的很糟糕。有关详细信息，请参阅为什么不应收缩数据文件。

Answer 2

好的，首先是的，如果您想在出现问题时恢复，即使每天进行完整备份，日志也是必要的。我们每 15 分钟备份一次事务日志。问题是您没有备份事务日志，这就是日志增长如此惊人的原因。如果您正在执行正确的事务日志备份，则几乎不需要收缩事务日志。

在截断日志之前，您需要备份数据库。我建议在非工作时间执行此操作，以免在备份和截断之间插入新数据。然后设置适当的事务日志备份，这样您就不会再遇到这个问题。

至于影响性能，在不知道你的系统硬件和使用情况的情况下，这很难说。