我有许多从代码调用的存储过程ExecuteNonQuery。
一切都很好，但是我的两个存储过程今天开始间歇性超时：
超时已过。在操作完成之前超时时间已过或服务器没有响应。该语句已终止。
如果我从管理工作室手动执行 sp 它仍然很好。
我的数据库中最近没有任何变化 - 我的命令超时是默认值。
有什么线索吗？
编辑
反对 SP 的桌子正在运行它是巨大的 --> 15 Gigs。重新启动盒子 - 同样的问题，但这次也无法让 sp 从 Management Studio 运行。
谢谢！
JohnIdol
问问题
29191 次
9 回答
7
Management Studio 对其运行的查询/命令设置无限超时。您的代码数据库连接将有一个默认超时，您可以在命令对象上更改该超时。
于 2009-02-05T11:19:59.067 回答
7
尝试重新编译这些程序。我有几次这样的问题并没有找到问题的原因，但重新编译总是有帮助的。
编辑：
要重新编译 proc，你去管理工作室，打开程序修改并按 F5 或执行：EXEC sp_recompile 'proc_name'
于 2009-02-05T11:26:30.457 回答
5
这通常与：
- 由于过度急切的计划重用（参数嗅探）导致的错误查询计划
- 不同的 SET 选项 - 特别是 ANSI_NULLS 和 CONCAT_NULL_YIELDS_NULL
- 锁定（您可能有更高的隔离级别）
- 需要重建索引/更新统计信息/等
SET 选项可能导致某些索引类型不可用（例如，持久计算列上的索引 - 包括“提升”xml/udf 查询）
于 2009-02-05T11:22:11.883 回答
3
您是否设置了命令超时？您的数据库中的某些内容最近是否发生更改导致此过程需要更长的时间？
如果您必须诊断锁定问题，则需要使用 sp_lock 之类的东西。
你能分享你的一个过程的来源吗？
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
于 2009-02-05T11:19:36.523 回答
2
好的 - 这就是我最终修复它的方式。
具有 4500 万条记录的表上的聚集索引正在杀死我的 SQL 服务器 - 代码中的每次插入都会导致答案中描述的令人讨厌的超时。增加超时容限并不能解决我的可伸缩性问题，所以我玩弄索引并使主键上的聚集索引非聚集解除了这种情况。
我很感激对此发表评论，以更好地了解这是如何解决问题的。
于 2009-02-24T21:57:40.963 回答
1
您可能需要更新数据库的统计信息。最近表上的索引是否也发生了变化？
检查sp的执行计划，看能不能找到瓶颈。即使它之前运行正常，它也可能被调整为更有效地运行。
您还返回多少数据？过去我们遇到过设计不佳的 SQL 问题，直到累积报告开始在结果集中包含更多数据时才会出现。不知道你的 sps 做了什么，很难说这是否可能，但值得一提的是你要调查一下。
于 2009-02-05T15:53:14.927 回答
1
SQL Server 在返回给用户之前将无限期地等待。很可能设置了客户端超时属性。例如，您可以为 ADO 命令对象设置超时属性。
于 2009-02-06T11:51:23.103 回答
0
在其上获取 SQL 分析器，比较在 Management Studio 中和通过您的应用程序运行它的结果。
于 2010-08-19T15:58:18.337 回答
0
就我而言，我只是重新组织了操作表的集群索引，超时问题解决了。查询时间也select * from table减少到 2 秒，在重组索引之前几乎是 30 秒 +
于 2020-05-02T15:38:17.157 回答