TempDB上的DDL争用

我有一个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争用的原因，而不必在干草堆中寻找针头？

我已经看到了这个问题，最终发布的修复程序实际上是我使用Microsoft CSS的直接结果。没有公开的知识库文章可解决此问题。请确保已对SQL Server 应用Service Pack 4和最新的累积更新（在撰写本文时，这是累积更新＃3（9.00.5259））。

在发布此修补程序之前，Microsoft的建议是仅停止创建#temp表（类似于KB＃916086）。由于这将意味着大量重写许多报告过程，因此，我的解决方法（无论跟踪标志或临时文件布局如何）都是每隔一个周末重新启动集群。uck

为了跟踪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-临时表延迟删除对某些工作负载不起作用。” 您可能必须先支付案件费用，但由于是错误，应退还该费用。

您可能需要跟踪标志1118

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

知识库文章328551中介绍了TF

我对此没有直接经验，但听起来像我读过的

我认为您已经拆分了TempDB数据文件以尝试减轻争用（显然是首先通过预生产）。如果您很勇敢，请考虑Paul Randal权威引用的跟踪标志：http ://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230 ） -tempdb应该始终每个处理器core.aspx有一个数据文件

关于造成疼痛的原因，您需要进行一些调查工作：

• 这才刚刚开始发生吗？有什么变化？
• 服务器是否处于内存压力下，因此必须在TempDB中进行排序？
• 是否正在运行诸如CheckDB或联机重新索引之类的DBA流程？
• 使用了更多的隔离级别还是服务代理？看看sys.databases

在此Microsoft TempDB文档的底部有一个很好的查询，以尝试确定正在使用tempdb的内容：http : //technet.microsoft.com/zh-cn/library/cc966545.aspx

如果您仍然希望对此进行跟踪，那么我最近在同步表删除方面也遇到了类似的奇怪性能问题。如果在运行SQL 2005的sql实例上有大量数据库（> 100个左右），并且有许多临时表创建和删除语句，则可以得到缓慢的临时表删除。检查从sys.dm_db_index_usage_stats返回的行数可以立即将其排除为罪魁祸首。

KB文章介绍了该问题。http://support.microsoft.com/kb/2003031

当sys.dm_db_index_usage_stats具有大量行时，查询性能会降低

请考虑以下情形：

在Microsoft SQL Server 2005中，您经常执行DDL操作，其中涉及删除和重新创建许多表（尤其是tempdb数据库中的临时表）。在sys.dm_db_index_usage_stats动态管理视图（DMV）中，您有大量条目（100,000个或更多）。

取自我对此问题的接受答案。那里还有更多细节。 SQL 2005中的慢速表格删除