为什么缩小 TEMPDB 日志会导致缓慢？

Question

我最近在收到日志驱动器已满的警报后，不小心将 tempdb 日志缩小到几乎 0。我被告知这会导致缓慢。有人可以解释为什么它会导致缓慢吗？

Answer 1

我会问告诉你这件事的人，至少听听他们为什么认为这会降低性能。

原因之一是您的 TLOG 不会保持在 0。由于您将其缩小得如此之小，我认为您已设置了自动增长。根据您的配置方式，它每次都会增加一定数量，或者每次增加一定比例的大小。因此，每次您的事务日志需要增长时，SQL Server 都必须执行工作，您可能会注意到有关性能的问题。

下面的第一个链接详细介绍了主要原因：

当事务日志的自动增长机制启动时，SQL Server总是必须对添加到文件末尾的新块进行零初始化。无论您的 SQL Server 实例是否以“即时文件初始化”特权运行，都没有关系——事务日志始终初始化为零。

更有意义的是为该文件设置专用驱动器，并将LOG文件设置为驱动器的大小。当你知道它只会再次增长时，为什么缩小到 0，让你在同一个地方，它的大小，导致碎片等？

• 为什么事务日志自动增长会降低您的性能
• 使用增长百分比或 1MB，文件增长缓慢
• 微软对 AutoGrow 的考虑

tempdb使用简单的恢复模型并在发出检查点时清除日志。这会在日志使用率达到 70% 时自动发生，并且在 的情况下tempdb，它不会强制将脏tempdb页写入磁盘。请参阅Paul Randall 对此的帖子。如果可能，在检查点期间 VLF 也将处于非活动状态。当您缩小日志时，VLF 将被删除。

• Paul Randal 提高日志吞吐量的 8 个步骤（参见 7-8）
• Pinal Dave 减少高 VLF 计数

Answer 2

还有一点要添加到现有的两个很好的答案中。

一旦确定了 tempdb 的最佳大小，您应该手动将其设置为该大小。如果在系统打补丁时 SQL 每月重新启动时没有这样做（假设您每月打补丁），它将重置为较小的大小并需要增长，从而提供其他答案中提到的性能问题。

USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'temp2', SIZE = 2560000KB )
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', SIZE = 2560000KB )
GO

还要确保提供合理的自动增长设置。它应该是一个以 MB 为单位的值，永远不要使用百分比。

Answer 3

当文件因事务而增长时，该事务会在文件增长时暂停。使用该文件的任何其他事务也可能受到影响。这是对文件系统上增加文件的压力的补充，尽管分离文件可以帮助解决这个问题。

日志文件，特别是必须在它们可以使用之前增长和归零。但是，您可以为数据文件启用即时文件初始化。

理想情况下，您应该让 tempdb 增长到它需要的大小并将其保留在那里，尽管如果错误的事务是导致增长的原因，则可以将其缩小到正常大小。但是将其缩小到 0 并不是最好的操作。