收缩SQL Server日志文件如何影响性能？

我有一个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

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

我每天执行两次完整备份，因此就数据前滚而言，确实不需要日志。

我真的建议阅读Paul S. Randal 的“正确进行事务日志大小管理的重要性”。

最典型的是，只有两种非常好的方法来进行事务日志处理：

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

2. 使用SIMPLE恢复模型，您无需担心LOG文件的大小，而是执行常规的完全备份。

与LOG文件的截断和性能有关的是，当要增加LOG文件时（在上面链接的博客文章中的引言），您总是会受到性能的影响：

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

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

首先，是的，如果您想在出现问题的情况下恢复工作，则即使每天进行完整备份也需要日志。我们每15分钟备份一次我们的交易日志。问题在于您没有备份事务日志，这就是为什么日志如此大幅度增长的原因。如果您要进行正确的事务日志备份，则几乎不需要收缩事务日志。

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

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

事务日志增长多快？如果速度相当快，则将性能降低到几乎没有，这将影响性能，因为它需要花一些时间将其恢复。这并不意味着您不应该不时缩小它，而是您必须考虑大小问题，而不是仅仅缩小到最小。性能打击很大吗？可能不是，但这取决于服务器的负载（事务数量等）。

我发现有问题的一件事是“我每天执行2次完整备份，因此就数据前滚而言，实际上并不需要日志。” 对于完整备份之间的时间点，日志非常重要。即使每天两次，也不能消除用于灾难恢复的日志文件的需求，除非这是一个只读数据库（如果是只读数据库，则不会看到日志文件的大量增加）。