哈希/排序溢出到tempdb中的频率是多少？

我们的企业应用程序使用SQL Server进行数据存储，并且主要是OLTP系统。但是，我们应用程序的重要组成部分会产生大量的OLAP工作负载。

我们对tempdb的写入延迟约为100毫秒。这种趋势发展随着时间的推移，和ALLOW_SNAPSHOT_ISOLATION关断。我们正在对有关此问题的问题进行故障排除，到目前为止，我们发现的唯一有趣的事情是，有大量散列和排序溢出到tempdb。我们推测这是来自我们的OLAP工作负载。

题

涉及什么频率的泄漏？任何？每秒多少溢出？我们的初步数据表明，每秒大约有2次哈希溢出，每分钟大约25次分类溢出。

这种溢出的频率是否可能成为我们高tempdb写延迟的主要原因？

其他资讯

根据内核数的建议，我们正在为tempdb使用多个文件。tempdb文件位于RAID 1 + 0 SAN（具有高性能SSD）上，但与主DB数据和日志文件位于同一设备上。tempdb文件的大小足够大，以至于它们很少增长。我们没有使用跟踪标志1117或1118。另一个变量是，此设置被许多不同的数据库共享，这些数据库都承受着中到高负载。

我们的100 ms写延迟远远大于我们在MSDN，SQL Skills和其他站点上找到的tempdb写延迟可接受的范围。但是，其他数据库的写入延迟很好（小于10ms）。基于其他统计数据，看来我们在大量使用tempdb，尤其是对于内部对象。因此，我们正在深入研究以找出为什么我们的应用程序如此大量地使用内部对象。

我们的平台上确实存在实际性能问题，这些问题以不同的方式体现出来。我们一直在监视性能计数器，查看DM视图，并分析我们的应用程序行为，以尝试挖掘系统的资源使用特征。我们现在专注于溢出，因为我们已经了解到溢出具有严重的负面影响，因为它们是在磁盘上而不是在内存中执行的。而且我们似乎有大量的泄漏事件，但是我想就人们认为“高泄漏”的问题征求一些意见。

这种溢出的频率是否可能成为我们高tempdb写延迟的主要原因？

是的，这是可能的，尽管通常情况下，泄漏的平均大小以及泄漏的深度（即递归哈希泄漏，多次遍历排序）比频率本身更为重要。

SQL Server提供了广泛的指标和DMV信息，以帮助您解决导致tempdb压力的各种因素，在Microsoft技术文章“在SQL Server 2005中使用tempdb”中讨论了许多因素（适用于2005年以后的所有版本） ）。

您应该能够使用该文档中包含的指导和诊断查询来开始确定任何tempdb压力的主要原因。不要仅仅因为ALLOW_SNAPSHOT_ISOLATION未启用而忽略例如版本存储活动。除了快照隔离之外，许多功能还使用版本存储（例如触发器，MARS，RCSI）。

如果排序和哈希溢出确实在很大程度上是重要的，那么您可能需要为此设置一些特定的监视。取决于您的SQL Server版本，这并不总是像人们希望的那样简单。要将排序和哈希溢出与导致它们的特定查询联系起来，需要使用事件通知或扩展事件。SolidQ文章“ 识别和解决排序警告 ”包含详细信息和一些有关解决常见原因的良好常规建议。

您还应该与存储团队合作，确定多少高延迟归因于您的工作负载，多少来自其他共享用途以及重新配置的选项。您对SQL Server指标的分析以及SAN员工能够提供的任何指标都将有助于此讨论。