TempDB性能爬行;我们应该重启吗？

Question

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

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

建议的解决方案：重新启动SQL服务器。当SQL Server关闭时，重新启动托管大多数TempDB文件的驱动器阵列。此外，在SQL关闭时，重新启动网络连接以绕过网络交换机，以尝试消除硬件上任何缓慢的来源。

这是一个好主意还是在黑暗中拍摄？有任何想法吗？ 提前谢谢。

Answer 1

17？谁想出那个号码？ Please read this和this - 很少有情景＆gt; 8个文件将有所帮助，特别是如果您只有2个底层阵列/控制器。一些建议：

1. 使用偶数个文件。大多数人从4或8开始，只有在他们已经证明他们仍然存在争用时才会增加（并且还知道他们的基础I / O实际上可以处理更多文件并使用它们扩展;在某些情况下它将没有效果或完全相反的效果 - 不同的驱动器号并不一定意味着更好的I / O路径。）
2. 确保所有数据文件的大小相同，并且具有相同的自动增长设置。拥有17个不同大小和自动增长设置的文件将会失败循环 - 在很多情况下，由于SQL Server执行比例填充的方式，将只使用一个文件。有一个奇数似乎......好吧，对我来说很奇怪。
3. 删除5个额外的日志文件。 They are absolutely useless。
4. 使用跟踪标志1117确保所有数据文件同时增长并且（因为2.）以相同的速率增长。请注意，此跟踪标志适用于所有数据库，而不仅仅适用于tempdb。 More info here。
5. 您还可以考虑跟踪标记1118来更改分配，但请read this first。
6. 确保instant file initialization已启用，以便在展开文件时不必将文件清零。
7. 预先调整tempdb文件的大小，以便在正常的日常活动中不必增长它们。不要缩小tempdb文件，因为它们突然变大了 - 这只是一个冲洗和重复操作，因为如果它们变得那么大，它们会再次变大。在此期间，您不能租用已回收的空间。
8. 如果可能，请在其他地方执行DBCC CHECKDB。如果你经常运行CHECKDB，那么！拍拍自己的背部。但是，这可能会对tempdb - please see this article on optimizing this operation产生影响，并在可行的情况下将其从生产实例中拉出来。
9. 最后，验证您所看到的争用类型。你说tempdb性能爬行，但是以什么方式？你是如何测量的？ Some info on determining the exact nature of tempdb bottlenecks here和here以及here和here以及here。

您是否考虑过显式减少使用tempdb（更少的#temp表，@ table变量和静态游标 - 或完全使用游标）？您是否大量使用RCSI，或MARS或LOB类型的局部变量？