TempDB 上的 DDL 争用

Question

我有一个 SQL Server 2005 Standard x64，它在过去几个月中遇到了 TempDB DDL 争用问题。服务器将在等待资源 2:1:103 上发生争用（等待类型为 PAGELATCH_EX）。

当服务器负载正常时，该问题似乎偶尔会发生。我一直在监视“破坏临时表”的比率，当我们在 2:1:103 出现 PAGELATCH_EX 问题时，它可以跳到 5,000+。从我读过的内容来看，这个计数器大部分时间应该是 0，但我们的大部分时间似乎都保持在 300-1100 之间。只有当系统上的用户很少时，计数器才会变为 0。

如何缩小导致 tempdb 上 DDL 争用的范围，而不必在大海捞针中寻找针头？

Answer 1

我已经看到了这个问题，最终发布以修复它的修补程序实际上是我使用 Microsoft CSS 的案例的直接结果。没有用于修复的公共知识库文章。请确保您已将Service Pack 4和最新的累积更新应用到 SQL Server（在撰写本文时，即累积更新 #3 (9.00.5259)）。

在修补程序发布之前，微软的建议是简单地停止创建 #temp 表（很像KB #916086）。由于这意味着大量重写数十个报告程序，因此在我的情况下（无论跟踪标志或临时文件布局如何）的解决方法是每隔一个周末重新启动我们的集群。哎呀。

为了跟踪 tempdb 使用情况，有几个脚本可以提供帮助，例如，请参阅 Adam Machanic 的sp_whoIsActive，特别是：

• sp_whoisactive：分析 Tempdb 争用
• 如何确定哪个查询正在填满 tempdb 事务日志？

还有来自@SQLSoldier 的这个脚本（以及评论中的脚本）：

• 打破 TempDB 争用

我会确保您的所有游标都在使用LOCAL STATIC READ_ONLY FORWARD_ONLY（请参阅this和this），并查看是否有任何已知的昂贵查询广泛使用#temp表/@table变量、CTE，或者可能包含不必要的排序或导致散列连接...所有这些都可能导致问题（我怀疑您会找到一个黄金原因）。作为“物超所值”的起点，最简单的彻底修复是使用适当且廉价的光标选项而不是默认值。

与此同时，我会 (a) 安装 CU#3 和 (b) 调用 PSS。告诉他们您正在寻找一个非常具体的修复程序，该修复程序已被确认为错误并作为私人修补程序发布给其他用户：“VSTS #109112 - 临时表延迟删除无法针对某些工作负载进行扩展。” 您最初可能需要支付案件费用，但由于这是一个错误，因此应退还费用。

Answer 2

我假设您已经拆分了 TempDB 数据文件以尝试缓解争用（显然首先是通过预生产）。如果您更勇敢，请考虑 Paul Randal 权威引用的跟踪标志：http ://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230 ) -tempdb-should-always-have-one-data-file-per-processor-core.aspx

至于是什么引起了痛苦，你需要做一些调查工作：

• 这才刚刚开始发生吗？发生了什么变化？
• 服务器是否处于内存压力下，所以必须在 TempDB 中进行排序？
• 是否有任何 DBA 进程（如 CheckDB 或在线重新索引）正在运行？
• 是使用了更奇特的隔离级别还是服务代理？看看 sys.databases

在这个 Microsoft TempDB 文档的底部有一个很好的查询来尝试找出使用 tempdb 的内容：http : //technet.microsoft.com/en-gb/library/cc966545.aspx

Answer 3

您可能需要跟踪标志 1118

先看看Paul Randal 关于 tempdb 的神话，以及他的TF 1118 文章

TF 在KB 328551 中进行了描述

我没有这方面的直接经验，但这听起来像我读过的