使用SQL Server Profiler识别超时原因

Question

我们在两个应用程序（一个ASP.Net和一个WinForms）SQL Server应用程序上遇到看似随机的超时。我让SQL Profiler在一小时内运行，看看可能导致问题的原因。然后我隔离了超时发生的时间。

存在大量读取，但是当超时错误发生时以及它们不发生时，读取没有大的差异。在此期间几乎没有写作（主要是因为每个人都有时间超时而无法写作）。

实施例： 超时发生在11:37。在超时之前，平均每分钟有1500笔交易，大约有5709219条读数。

这似乎很高，除了在超时（超过十分钟的跨度）之间的时间段内，每分钟的事务数量和读数一样多。读取在超时前跳跃一点（跳到6005708以上），但在非超时期间，它们会高达8251468.两个应用程序都会发生超时。

这里更大的问题是，这只是在过去一周内开始发生，并且应用程序已经启动并运行了几年。所以是的，Profiler已经为我们提供了大量数据，但目前的问题是超时。

我是否应该在Profiler中寻找其他东西，或者我应该在服务器上移动到性能监视器（或其他工具）？

一个可能的罪魁祸首可能是数据库大小。数据库相当大（> 200 GB），但AutoGrow设置设置为1MB。可能是SQL Server正在调整自身大小并且该事务在分析器中没有显示出来吗？

非常感谢

Answer 1

感谢这里的帮助，我能够找出一些瓶颈，但我想概述我的过程，以便可能帮助任何人完成这个过程。

1. 发现＃1问题是从SQLDiag和其他工具中找到的大量LOCK_MK_S条目。

2. 在两个不同的时间段内运行Trace Profiler。比较类似方法的持续时间让我发现某些UPDATE调用总是花费相同的时间，超过10秒。

进一步的调查发现，这些UPDATE存储过程正在使用占用太多时间的触发器更新表。由于触发器可能会在完成时锁定表，因此它会影响其他所有查询。 （请参阅注释部分 - 我错误地指出触发器将始终锁定表 - 在我们的示例中，触发器阻止锁被释放）

观察使用触发器进行重大更新。