0

[来自数据库管理员站点的交叉发布，希望它可以在这里获得更好的牵引力。我将酌情更新任一站点。]

我在 SQL Server 2005 (SP2) 中有一个存储过程，其中包含一个如下查询（为清楚起见进行了简化）

SELECT * FROM OPENQUERY(MYODBC, 'SELECT * FROM MyTable WHERE Option = ''Y'' ')
OPTION (MAXDOP 1)

当这个 proc 运行（并且只运行一次）时，我可以看到该计划出现在 sys.dm_exec_query_stats 中，具有较高的“total_worker_time”值（例如 34762.196 毫秒）。这接近过去的时间。但是，在 SQL Management Studio 中，统计数据显示的 CPU 时间要低得多，正如我所期望的（例如 6828 毫秒）。该查询需要一些时间才能返回，因为它正在与之交谈的服务器速度很慢，但它不会返回很多行。

我知道 SQL Server 2005 中的并行查询可能会出现奇怪的 CPU 时间的问题，这就是为什么我尝试使用查询提示关闭任何并行性（尽管我真的不认为任何案子）。

我不知道如何解释查看 CPU 使用率的两种方式可能不同的事实，也不知道这两种方式中哪一种可能是准确的（我有其他理由认为 CPU 使用率可能是更高的数字，但它是难以测量）。谁能给我一个指导？

更新：我假设问题出在 OPENQUERY 上，所以我尝试查看不使用 OPENQUERY 的长时间运行的查询。在这种情况下，统计信息（通过设置 STATISTICS TIME ON 获得）报告的 CPU 时间为 3315 毫秒，而 DMV 给出的时间为 0.511 毫秒。同意每种情况下的总经过时间。

4

1 回答 1

0

total_worker_timeinsys.dm_exec_query_stats是累积的 - 它是当前编译的查询版本的所有执行的总执行时间 - 请参阅execution_count这代表的执行次数。

last_worker_time请参阅min_worker_time或max_worker_time了解个别处决的时间安排。

参考：http: //msdn.microsoft.com/en-us/library/ms189741.aspx

于 2012-01-25T12:19:55.447 回答