CXCONSUMER 上的工作等待

Question

我们有一个关于 SQL Server 代理作业的过程，这个作业开始在事务上挂起好几个小时，等待统计数据为 CXCONSUMER 并且永远不会完成。问题是在我们注意到它挂起之后，我们终止了工作并在此期间手动启动，并且工作运行良好并完成。但是现在无论是手动启动还是 sql 代理作业似乎都没有完成并等待 CXCONSUMER。

根据 sp_who2、sp_whoisactive 和 sql server profiler，没有它正在等待的活动锁。它不断产生 CXCONSUMER 和它的处理器时间，基本上什么都不做。这是3h后的执行计划——

另一个症状是当此作业运行时，无法通过属性访问 tempdb 我收到此错误“属性 SpaceAvailable 不适用于数据库‘[tempdb]’。此对象可能不存在此属性，或者可能由于不足而无法检索访问权限”，尽管 tempdb 上有可用空间。

我会感谢你在这件事上的帮助。

感谢你并致以真诚的问候，

Answer 1

这个问题实际上有两个问题：

1. 为什么查询慢？
2. 为什么无法访问 tempdb 属性？

让我们从#2 开始。

为什么无法访问 tempdb 属性？

您收到此错误：

无法显示请求的对话框。(SqlMgmt) 属性 SpaceAvailable 不可用于数据库“[tempdb]”。此对象可能不存在此属性，或者可能由于访问权限不足而无法检索。(Microsoft.SqlServer.Smo)

当您在事务中创建临时表时会发生这种情况。该CREATE TABLE持有系统表元数据锁，阻止查询来填充数据库属性窗口，并导致该对话框的时间开出与显示此错误。

如果您在 SSMS 中运行此语句，并尝试同时打开 tempdb 属性窗口，我希望它会打开得很好：

SELECT o1.object_id
INTO #blep
FROM sys.objects o1
CROSS JOIN sys.objects o2
CROSS JOIN sys.objects o3
CROSS JOIN sys.objects o4
CROSS JOIN sys.objects o5;

但是，将相同的查询放入事务中，您将收到您报告的上述错误：

BEGIN TRANSACTION
SELECT o1.object_id
INTO #blep
FROM sys.objects o1
CROSS JOIN sys.objects o2
CROSS JOIN sys.objects o3
CROSS JOIN sys.objects o4
CROSS JOIN sys.objects o5;

虽然您没有提供计划中包含的代码之外的代码，但该行为表明您SELECT...INTO正在事务中发生，类似于上面的示例。

我建议永远不要在事务中创建临时表，因为 tempdb 中的系统表被阻塞。除了像数据库属性窗口那样的操作问题之外，这还会影响并发性。

如果您的程序需要使用事务，您应该在事务之外创建表，然后开始事务并做必要的工作。如果您依赖于SELECT...INTO定义架构的行为（例如，使用动态/未知架构），请使用SELECT...INTO...WHERE 1=2;将表创建为空，然后在此之后开始您的事务并进行工作。

现在，转到另一个问题：

为什么查询慢？

我不确定sp_whoisactive输出中的哪一行与您的查询相关。他们都？Session_id 797 显示高CXCONSUMER等待，并且已经运行了 2 个小时。我会假设这是有问题的会话。它在 2 小时 12 英里的“实时”时间（132 分钟）内执行了近 5790 万毫秒的 CPU 周期（967 分钟）。这大约是“真实”时间的 7 倍 CPU 时间——这当然表明它正忙于并行工作。

我可以从架构中看出这是一个 SAP 数据库。SAP 模式有点古怪，该MANDT列是每个聚集复合索引的前导列。该列基本上是“公司代码”，用于分隔各个子公司的数据。SAP 在每个查询的连接/过滤谓词中提供此列，以确保它使用正确公司的数据。如果您的公司没有为不同的子公司保留单独的账簿，则该MANDT列始终是完全相同的值。

由于非选择性的谓词被应用，它可以欺骗SQL Server的进入呈现出寻求对聚集主键，当它真正做一个表扫描。如果每一行都有一个值AMTWOfor MANDT，并且您查询AND MANDT = 'AMTWO'，优化器可能会想“嘿，这是 PK 的前导列，我可以找到它！” 但实际上，它会查找该值的第一次出现（即第一行）并通读该值的最后一次出现（即最后一行）。因为每一行都是完全相同的值，所以它必须扫描每一行，即使它在计划中显示为搜索。

现实情况是有一个更好的索引可以使用，但 SQL Server 没有意识到另一个索引（或索引组合）会表现得更好。

此外，根据您的 SQL Server 版本以及您是否使用Trace Flag 2389，SAP 经常会遇到与他们大量使用日期作为关键事务数据相关的“升序关键问题”。

这两个问题都可以通过积极更新SAP 数据库上的统计信息来解决。

您的查询当然可能比统计数据更多，但根据我在 SAP 方面的经验，确保您拥有最新的统计数据将是我的首要任务。

你说它“开始挂起交易好几个小时”......它以前运行的速度有多快？它处理类似数量的数据是否很快？该计划表明它正在处理超过 100 万行#repositioning、20 万行#stock和 6500 万行MSEG——所以我不希望查询开始时非常快。

更新统计信息后，我很想捕获执行此代码的实际IO 和 CPU 成本，使用Plan Explorer 之类的东西，因为这通常可以更深入地了解问题，尤其是在 SQL Server 具有的情况下选择了“坏”计划，并且存在更好/更快的计划但未选择。