存储过程的间歇性 SQL Server 超时和差异很大的执行时间答案

【问题标题】：Intermittent SQL Server Timeouts and wildly varied execution times for stored procs存储过程的间歇性 SQL Server 超时和差异很大的执行时间
【发布时间】：2010-12-04 16:39:45
【问题描述】：

我的 SQL Server 2005 存在问题，其中存储的过程，特别是运行批量插入的过程，有时需要很长时间才能执行。这个存储过程，我们称之为 DatabaseUpdate，大约需要 2 秒才能完成。然而，在 20-40% 的时间里，它花费的时间远不止于此，而且很常见的是它会在 30 秒后超时。

这很奇怪，我有一个非常受控的环境。我目前正在查看的日志显示了一个周期，其中定期发生完全相同的事件。有少数客户端，它们都基于计时器发出请求，这些机器都在运行原子时钟同步应用程序。因此，我几乎可以肯定地说，每五分钟发生一次相同的事件序列，但是我将 100Kb 文件导入数据库的存储过程的执行时间在 1.5-30+ 秒之间变化。

我之前没有注意到，因为我只看到超时错误，是每隔一次更新就会发生较长的执行时间，所以时间看起来像这样：

10:30 2062 毫秒 10:35 24250 毫秒 10:40 1921 毫秒 10:45 25703 毫秒 10:50 1734 毫秒 10:55 25406 毫秒 11:00 1625 毫秒

有什么想法吗？

【问题讨论】：

标签： sql-server sql-server-2005 timeout

【解决方案1】：

根据 Mitch 的建议，我还建议通过运行 SQL 跟踪来解决您的问题，以验证存储过程的每次调用是否使用相同的“实际”而不是“估计”执行计划。

此外，请验证每次执行/BULK INSERT 是否正在处理相同或相似数量的记录，因为过程插入的记录自然越多，执行所需的时间就越长。

您是否考虑过您的数据库的大小可能不足以支持您的插入操作？例如，您的数据库数据文件是否需要增长以适应所有其他过程的执行？

如果这些元素在每次执行之间都相同，那么唯一会改变的其他元素就是数据库数据本身，因此需要调查统计数据和索引使用情况。

【讨论】：

我有，目前正在运行 Trace。文件大小始终在 20Kb 左右，我已经确认持续时间与读写次数无关。
您的数据库大小如何？是否发生自动增长事件以适应批量插入？
我没有看到任何自动增长事件发生。您能否准确说明您将如何验证“存储过程的每次调用都使用相同的“实际”而不是“估计”执行计划。”我已经比较了“Showplan Text (unencoded)”事件，没有区别，但你指的是别的东西。
不同的估计和实际查询计划是由过期的统计数据引起的，您已经排除了。
@Mitch Wheat：是的，非常正确。我想我正在尝试做的是鼓励发布者进行消除的调查过程，并确保将同类与同类进行比较，以便确定相同的两次处决之间的不同因素存储过程。

【解决方案2】：

查看您是否有任何日志增长或数据库增长事件。当数据库大小不正确时，它们将自动增长。在自动增长事件期间（可能在批量插入期间发生），数据库将冻结，直到文件增长并初始化 0。这个操作会持续很长时间（几十秒），并且随着数据库的增长而变长，因为默认的自动增长是从大小开始的百分比，所以自动增长越来越大。

要检查自动增长事件，请查看 ERRORLOG 和 SQL Server:Database/Log Growth 性能计数器值。

如果您有数据库增长事件，您必须将数据库大小设置为正确的大小。正确的值取决于您的实际数据负载。您还应该打开 NTFS initant 初始化，请参阅Instant Initialization - What, Why and How?。您不能将此设置用于日志文件。

【讨论】：

有时，当自动增长的百分比太小时，它会导致超时，因为它无法增长到足够快以使进程在超时之前工作。

【解决方案3】：

可能是 [b] 锁定问题吗？ SQL Profiler 显示了什么（也打开错误和死锁）？哪些资源正在（挂起）插入等待？

【讨论】：

【解决方案4】：

查看检查点。

我在加载大量数据时也看到过同样的情况。

问题是数据库引擎正在将脏页从内存写入磁盘。

使用 Perfmon 监控磁盘性能，如果是这种情况，您会在性能下降的同时看到磁盘使用量激增。

【讨论】：