4

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

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

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

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

4

1 回答 1

10

17？谁想出了这个数字？请阅读这个和这个- 很少有 > 8 个文件会有帮助的场景，特别是如果您只有 2 个底层阵列/控制器。一些建议：

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

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

于 2013-02-04T22:57:36.297 回答