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

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

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

建议的解决方案：重新启动SQL server。SQL server关闭时，重新启动承载大多数TempDB文件的驱动器阵列。此外，当SQL关闭时，重新进行网络连接以绕过网络交换机，试图消除硬件上的任何慢度源

这是一个好主意还是一次冒险？有什么想法吗？

---

提前谢谢。

17？谁想出那个号码的？和-很少情况下>8个文件会有帮助，特别是当您只有2个底层阵列/控制器时。一些建议：

使用偶数个文件。大多数人从4或8开始，只有当他们证明自己仍然存在争用时（并且知道他们的底层I/O实际上可以处理更多文件并随它们扩展；在某些情况下，它不会产生任何效果或完全相反的效果-不同的驱动器号并不一定意味着更好的I/O路径）才会增加争用

确保所有数据文件大小相同，并且具有相同的自动增长设置。拥有17个具有不同大小和自动增长设置的文件将击败循环-在许多情况下，由于SQL Server执行比例填充的方式，只能使用一个文件。而拥有一个奇数似乎。。。嗯，我觉得奇怪

清除5个额外的日志文件

使用跟踪标志1117确保所有数据文件在同一时间以相同的速率增长（因为2）。但请注意，此跟踪标志适用于所有数据库，而不仅仅是tempdb 您还可以考虑跟踪标志1118来改变分配，但是请。

确保已启用，以便文件在展开时不必归零

预先调整tempdb文件的大小，以便它们在正常的日常活动中不必增长。不要因为tempdb文件突然变大而收缩它们-这只是一个冲洗和重复操作，因为如果它们变大一次，就会再次变大。在这段时间内，你不可能把恢复的空间出租出去

如果可能，请在其他位置执行

DBCC CHECKDB

。如果您定期运行

CHECKDB

，耶！拍拍自己的背。但是，这可能会对tempdb造成损失，并在可行的情况下将其从生产实例中移除

最后，验证您看到的争用类型。你说tempdb的性能在爬行，但以什么方式呢？你是如何测量的？还有

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