tempdb日志文件的最佳做法

我在这里和那里已经读过许多关于如何配置tempdb数据文件的博客，但是我没有找到有关tempdb日志文件的任何信息。

这是我目前在tempdb中使用的策略：

• 我已使用Paul Randal的建议来分割tempdb数据文件
• 我已将tempdb数据文件的大小设置为最大，并禁用了自动增长。例如，我有100gb的可用磁盘空间，并将8个tempdb数据文件的大小分别设置为10gb。如布伦特·奥扎尔（Brent Ozar）所建议，这可以防止磁盘碎片，而且我的日志文件还有20GB可用空间。

但是就像我说的，没有人在谈论tempdb日志文件。我该怎么办？在我的设置中，此文件与tempdb数据文件位于同一位置。我应该与tempdb日志文件一起使用的大小和自动增长值是多少？

这实际上取决于要在事务日志中流过多少数据。看看今天的日志有多大。SQL启动时，您需要将日志配置为至少具有该大小。对于我的大多数客户，他们最终得到tempdb的3-4 Gig事务日志，其中仅包含几个VLF，并且一切运行正常且流畅。

如果您的硬件可以同时写入数据和同时记录日志以提高性能，则总是被告知要在单独的物理/磁盘阵列上存储日志文件。我猜想产生20G tempdb限制的限制可能会定义大小的答案。对于自动增长，这可能取决于您正在运行的事务，可用空间和磁盘上的其他资源。我通常会随意选择初始大小的1/6。

Aaron正确地配置TempDB取决于许多变量，例如您是否计划使用快照隔离等。这是MS / TN发行的旧SQL 2005白皮书，可能会帮助您，因为仍然有很多应用。具体来说，请查看“ tempdb日志记录所需的空间”，以便您可以查看tempdb日志中记录的事务类型，从而可以进行相应的设置。随着时间的流逝，您可能必须进行监视和调整。

就tempdb的authogrowth而言，我过去很不情愿地在报告服务器上禁用了此功能，而我所经历的行为是，它导致长时间运行的事务中止并回滚，这立即释放了日志空间，但这可能取决于在我的情况下，这种交易类型是大量的排序和联接操作（写得不好的报表查询）。我同意亚伦的建议，如果可能的话，建议避免使用这种方法，尤其是在交易量较大的情况下。