Question

我需要向管理层提供证据，证明使用游标的一组现有存储过程是导致我们出现大部分性能问题的原因。有人能指出我正确的方向找到脚本和查询来完成这个，拜托？例如，如何使用SQL Server 2005监视和测量游标等。

感谢。

====== UPDATE ============

管理层需要弹药收回第三方供应商，告诉他们以很少或没有成本改变他们的过程。由于这些是第三方触发我们的会计系统，我没有任何方法可以先重写它们。

除了痕迹（已经在做），还有其他我可以做的事情吗？我发现使用sys.dm_exec_cursors（0）可以让我快速获得exisitng游标列表。还有其他类似的东西吗？

Answer 1

因此，您进行了严格的测量并收集了执行时间和统计信息，显示问题程序是使用游标的，对吧？然后收集的信息是证明你的情况的一个很好的论据。如果你没有...那么你怎么知道游标？

首先查看sys.dm_exec_query_stats并按工时（CPU），经过时间（持续时间）和I / O收集最昂贵的查询。这些应该足以指出罪魁祸首并找出问题是否确实是因为游标是否存在。

如果游标确实是一个问题，那么它们也有专门的DMV，sys.dm_exec_cursors

例如，最常用的CPU经常执行的语句：

select top(10) substring(Text,
  statement_start_offset/2, 
  (statement_end_offset-statement_start_offset)/2) as Statement
  , *
from sys.dm_exec_query_stats q
cross apply sys.dm_exec_sql_text(sql_handle)
where execution_count > 100
order by total_worker_time/execution_count desc

Answer 2

最好的事情（时间允许）是将一些过程重写为基于集合的语句，然后将这两个过滤与等待分析进行比较（http://technet.microsoft.com/en-us/library/cc966413.aspx有一篇关于如何做这类事情的好文章）。没有前后，你的对手可能会说“基于集合不会更好:-)”

Answer 3

您可以运行SQL事件探查器并使用违规的sprocs捕获跟踪（这将为您提供重要的措施，如读取，CPU，持续时间）。

一个好主意是以其中一个为例，很容易重写为基于集合的方法，运行它并为此捕获探查器跟踪。这样，您就可以展示真实世界中的性能差异。

如果可能，（即不在生产中），您应该在运行每个版本的sproc之前清除执行计划和数据缓存，以便进行公平比较。

此外，您可以获得游标版本和基于集合的版本的执行计划。

在一天结束时，底线统计数据不言自明，因此在“之前”和“之后”进行比较将是有益的。

Answer 4

性能监视器（perfmon.exe）是实时分析SQL Server性能的绝佳工具。

监控游标，有什么好的查询/脚本可以做到这一点？

4 个答案: