TempDB性能爬行；我们应该重新启动吗？

Question

背景：我们在服务器上有17个不同的TempDB数据库文件和6个TempDB日志文件。它们分散在不同的驱动器上，但是托管在两个驱动器阵列上。

我看到磁盘IO响应时间超过了建议的限制。通常，您希望您的磁盘响应在5-10毫秒，没有超过200毫秒。我们在TempDB文件上看到了高达800毫秒的随机峰值，但只有一个驱动器阵列。

提出的解决方案：重启server。当SQL server关闭时，重新启动承载大部分TempDB文件的驱动器数组。此外，当SQL关闭时，重做网络连接以绕过网络交换机，以消除硬件上任何缓慢的来源。

这是个好主意还是暗处拍摄？有什么想法吗？提前谢谢。

Answer 1

17岁？是谁想出了这个数字？请看这个和这 --很少有超过8个文件会有帮助的场景，特别是当您只有两个底层数组/控制器时。一些建议：

1. 使用偶数的文件。大多数人从4或8开始，只有在他们证明自己仍然有争议时才会增加(并且知道他们的底层I/O实际上可以处理更多的文件并与它们进行缩放；在某些情况下，它不会产生任何效果或完全相反的效果-不同的驱动器号并不一定意味着更好的I/O操作)。
2. 确保所有数据文件的大小相同，并具有相同的自动增长设置。拥有17个不同大小和自动增长设置的文件将击败循环--在很多情况下，由于Server执行比例填充的方式，只有一个文件将被使用。有个奇数似乎..。对我来说很奇怪。
3. 摆脱你的5个额外的日志文件。他们是完全没用的。
4. 使用跟踪标志1117确保所有数据文件同时增长(因为有2)。以同样的速度。注意，此跟踪标志适用于所有数据库，而不仅仅是tempdb。这里有更多的信息。
5. 您也可以考虑使用跟踪标志1118来更改分配，但请使用先读这个。
6. 确保即时文件初始化是打开的，以便在文件展开时不必将其归零。
7. 预先调整你的tempdb文件的大小，这样它们就不必在正常的日常活动中增长。不要因为文件突然变大而收缩tempdb文件--这只是一次清洗和重复操作，因为如果它们有那么大的一次，它们就会再次变大。你不可能在这段时间内把恢复的空间租出去。
8. 如果可能，在其他地方执行DBCC CHECKDB。如果你定期运行CHECKDB，耶！拍你自己的背。然而，这可能会对tempdb 请参阅这篇关于优化此操作的文章。造成影响，并在可行的情况下将其从生产实例中删除。
9. 最后，验证所看到的争用类型。你说tempdb性能会爬行，但以什么方式？你是怎么测量这个的？关于在这里确定tempdb瓶颈的确切性质的一些信息和这里，这里，这里和这里。

您是否考虑过显式地使用tempdb (更少的#temp表、@表变量和静态游标-或者完全是游标)？您是在大量使用RCSI、MARS或LOB类型的局部变量吗？