0

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

谢谢。

========更新============

管理层需要将弹药带回给第 3 方供应商，以告诉他们以很少或没有成本的方式更改他们的 proc。由于这些是影响我们会计系统的第 3 方 proc，我没有办法先重写它们。

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

4

4 回答 4

4

因此，您进行了严格的测量并收集了执行时间和统计数据，表明问题过程是使用游标的过程，对吗？那么收集到的信息是证明你的情况的一个很好的论据。如果你没有……那你怎么知道是光标？

首先查看sys.dm_exec_query_stats并按工作时间 (CPU)、已用时间 (duration) 和 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
于 2009-12-17T22:35:45.227 回答
0

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

于 2009-12-17T22:31:08.207 回答
0

您可以运行 SQL Profiler 并使用有问题的存储过程捕获跟踪（这将为您提供重要的措施，如读取、CPU、持续时间）。

一个好主意是例如以其中一个作为示例，该示例很容易重写为基于集合的方法，运行它并为此捕获分析器跟踪。通过这种方式，您可以展示现实世界的性能差异。

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

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

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

于 2009-12-17T22:32:31.533 回答
0

性能监视器 (perfmon.exe) 是实时分析 SQL Server 性能的出色工具。

于 2009-12-17T22:32:55.680 回答