SQL Server 2005中使用OPENQUERY存储过程的高'total_worker_time'

[Cross从数据库管理员站点发布，希望能够在这里获得更好的牵引力。我会更新网站的任何适当]SQL Server 2005中使用OPENQUERY存储过程的高'total_worker_time'

我在SQL Server 2005（SP2），其中包含如下内容（简化为清楚起见）

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

当这个PROC一个查询的存储过程运行（并且只运行一次）我可以看到该计划出现在具有较高'total_worker_time'值（例如34762.196毫秒）的sys.dm_exec_query_stats中。这接近于经过的时间。但是，在SQL Management Studio中，统计信息显示的CPU时间要低得多，正如我预期的那样（例如，6828毫秒）。查询需要一些时间才能返回，因为它正在与之交谈的服务器缓慢，但它不会返回许多行。

我知道SQL Server 2005中的并行查询可以呈现奇怪的CPU时间的问题，这就是为什么我试图关闭任何与查询提示并行的幻灯片（虽然我真的不认为那里在任何情况下都是）。

我不知道如何解释查看CPU使用率的两种方法可能不同，也不知道两者中的哪一个可能是准确的（我还有其他理由认为CPU使用率可能更高数字，但它很难衡量）。任何人都可以给我一个指导吗？

UPDATE：我假设问题是与OPENQUERY，所以我试图寻找一个长时间运行的查询不使用OPENQUERY时间。在这种情况下，统计数据（通过设置STATISTICS TIME ON获得）报告CPU时间为3315ms，而DMV的时间为0.511ms。每种情况下的总使用时间达成一致。

来源

2012-01-23 Yellowfog

您能够提供可重复的测试案例，所以我们可以看到，如果我们得到了相同的结果？ –

我会尽力去做。 – Yellowfog

我试图生产一个测试平台，但唯一可以在CPU时间和流逝时间上获得真正差异的方法是对繁忙系统运行存储过程。进行人工等待并没有帮助。所以我很努力地想知道如何用这个属性来制作一个测试平台（或者至少是一个足够简单的可以在这里发布的测试平台）。 – Yellowfog

total_worker_time in sys.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-25 12:19:55

是的，谢谢，我应该在问题中明确指出，我只查看一次执行的统计数据。这可能是我错过了一些明显的东西，但这并不是我错过的明显的事情。 – Yellowfog

SQL Server 2005中使用OPENQUERY存储过程的高'total_worker_time'

回答

相关问题