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

Question

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

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

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

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

Answer 1

17？谁提出了这个数字？ Please read this和this - 极少数情况下，> 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类型的局部变量？