一些背景知识:我们在服务器上有 17 个不同的 TempDB 数据库文件和 6 个 TempDB 日志文件。它们分布在不同的驱动器上，但托管在 2 个驱动器阵列上。
我发现磁盘 IO 响应时间超出了建议的限制。通常，您希望磁盘在 5-10 毫秒内响应，任何时间都不超过 200 毫秒。我们在 TempDB 文件上看到高达 800 毫秒的随机峰值，但仅限于一个驱动器阵列。
建议的解决方案:重新启动 SQL 服务器。当 SQL Server 关闭时，重新启动托管大部分 TempDB 文件的驱动器阵列。此外，当 SQL 关闭时，重做网络连接以绕过网络交换机，以尝试消除硬件上任何缓慢的根源。
这是一个好主意还是盲目尝试？有任何想法吗？ 提前致谢。
最佳答案
17？谁想出了这个数字？ Please read this和 this - 很少有超过 8 个文件会有所帮助的情况，特别是如果您只有 2 个底层数组/ Controller 。一些建议:
- 使用偶数个文件。大多数人从 4 或 8 个开始，只有当他们证明仍然存在争用时(并且还知道他们的底层 I/O 实际上可以处理更多文件并随其扩展；在某些情况下，它不会有争用)，才会增加超过这个数量。效果或完全相反的效果 - 不同的驱动器号并不一定意味着更好的 I/O 路径)。
- 确保所有数据文件的大小相同，并且具有相同的自动增长设置。拥有 17 个不同大小和自动增长设置的文件将击败循环法 - 在很多情况下，由于 SQL Server 执行比例填充的方式，只会使用一个文件。奇数对我来说似乎……嗯，很奇怪。
- 删除 5 个额外的日志文件。 They are absolutely useless .
- 使用跟踪标志 1117 确保所有数据文件同时增长并且(因为 2.)以相同的速率增长。但请注意，此跟踪标志适用于所有数据库，而不仅仅是 tempdb。 More info here .
- 您还可以考虑使用跟踪标志 1118 来更改分配，但请read this first .
- 确保 instant file initialization启用，这样文件扩展时就不必归零。
- 预先调整您的 tempdb 文件的大小，以便它们在正常的日常事件期间不必增长。不要收缩 tempdb 文件，因为它们突然变大了 - 这只是一个冲洗和重复操作，因为如果它们曾经变大过一次，它们就会再次变大。在此期间您不可能出租回收的空间。
- 如果可能，请在其他地方执行
DBCC CHECKDB。如果您定期运行CHECKDB，那就太好了!拍拍自己的背。然而，这可能会对 tempdb 造成损害 - please see this article on optimizing this operation并在可行的情况下将其从生产实例中拉出。 - 最后，验证您看到的争用类型。你说tempdb性能爬行，但以什么方式爬行呢？你如何衡量这个？ Some info on determining the exact nature of tempdb bottlenecks here和 here和 here和 here和 here .
您是否考虑过显式地减少对 tempdb 的使用(减少 #temp 表、@table 变量和静态游标 - 或全部游标)？您是否大量使用 RCSI、MARS 或 LOB 类型的局部变量？
关于sql-server - TempDB性能爬取；我们应该重新启动吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14697128/