存储过程间歇性地超时了!

我有一些存储过程，我从代码中调用了带有 ExecuteNonQuery.

本来一切都很好，但我的2个存储过程今天开始间歇性地超时，内容是：。

"超时了在操作完成之前超时时间已过，或者服务器没有响应。语句已被终止。

如果我从management studio手动执行sp，还是一切正常。

最近我的db中没有任何变化--我的命令超时是默认的。

有什么线索吗？

EDIT

对SP的表正在运行它的巨大--> 15 Gigs.Rebooted盒子--同样的问题，但这一次不能让SP从管理工作室也运行。

谢谢!

7
投票

管理工作室对其运行的查询命令设置了无限超时。你的数据库连接从代码将有一个默认的超时，你可以改变在你的数据库连接上。命令对象.

6
投票

尝试重新编译这些程序。我遇到过几次这样的问题，但没有找到问题的原因，但重新编译总是有帮助的。

EDIT:

要重新编译proc，你去management studio，打开要修改的过程，然后按F5键或执行。EXEC sp_recompile 'proc_name'.

5
投票

这往往与以下情况有关

SET选项可能会导致某些索引类型无法使用（例如，持久计算列上的索引--包括 "推广的 "xmludf查询）。

3
投票

你的命令超时了吗？你的数据库中是否有什么东西最近发生了变化，导致这个过程需要更长的时间？

如果你必须诊断锁定问题，你将需要使用类似sp_lock的东西。

你能分享你的一个procs的源码吗？

2
投票

好吧--这就是我最后解决的方法。

在一个有4500万条记录的表上的集群索引正在杀死我的SQL服务器--每次从代码中插入都会导致答案中描述的讨厌的超时。增加超时容忍度并不能解决我的可扩展性问题，所以我玩弄了一下索引，并将集群索引放在主键上。非群集 解锁了这种情况。

我希望大家对此发表意见，以便更好地了解这如何解决这个问题。

1
投票

你可能需要更新数据库的统计数据。另外最近表的索引是否有变化？

检查sp的执行计划，看看能否找到瓶颈。即使之前运行得很好，可能也可以调整一下，让它运行得更有效率。

另外你返回的数据有多少？我们过去曾遇到过SQL设计得不好的问题，直到累积报告开始有更多的数据在结果集中才显示出来。不知道你的SPS是怎么做的，很难说这是否是一种可能性，但值得你去调查。

1
投票

SQL Server在返回给用户之前会无限期地等待。更有可能是客户端设置了超时属性。例如，你可以设置一个 ADO命令对象的超时属性.

0
投票

在上面弄个SQL剖析器，比较一下在Management studio中运行和通过你的应用运行的结果。

0
投票

在我的案例中，我只是重新组织了操作表的集群索引，超时问题解决了。另外 select * from table 查询时间减少到2秒，而之前重组索引几乎是30秒+。