2010-02-04 86 views
0

我遇到了SQL Server 2005的问题,其中存储过程似乎随机挂起/锁定,并且从不返回任何结果。SPROC挂在SQL Server 2005中

存储过程所做的是调用一个函数,该函数又使两个不同函数的联合 - 返回相同类型的数据,但是来自不同的条件。没有进展。我不认为这是挂起的功能,因为还有其他SPROC可以在没有问题的情况下调用相同的功能,即使第一个锁定了也是如此。

在SPROC挂起后,任何进一步尝试调用它都会导致超时 - 而不是调用本身,但响应时间太长,因为没有返回结果,代码将引发异常。

在相对低负荷的系统中,在两个月内至少发生过三次。重新启动SQL Server解决了这种情况,但我并不认为这是解决问题的方法。

我查找了信息,并发现有关查询缓存将会损坏。然而,这是关于动态SQL字符串,我的问题不是。我想它可能仍然是查询缓存。

有没有人有同样的问题,如果是这样,你做了什么(不要说“每天早上重新启动SQL Server”))?有没有什么方法可以调试这个问题,试图准确地找到出错的地方?我不能重现这个问题,但当它再次出现时,如果我知道在哪里仔细观察,这将是一件好事。

我不认为它有什么区别,但只是为了记录,SPROC从.NET 3.5代码调用,使用Entity Franework。我说它没有什么区别,因为当我测试过直接从SQL Server Management Studio执行SPROC时,没有结果返回。

回答

2

这是嗅探

重新启动SQL服务器最有可能的参数清除计划缓存。如果重建统计数据或指标的问题也就会迎刃而解“ALTER INDEX”和“sp_updatestats”

我建议使用“参数遮蔽”(不重新编译!)绕过它

SO由我来回答已经:

+0

我会研究这个。这应该按照每晚的计划任务完成吗?在每次查询之前重建索引并更新统计信息不是一个可行的解决方案。 :) –

+1

是最佳实践。它仍然会发生,但是这对于参数嗅探来说是一个很好的测试,因为存储计划被统计更新无效 – gbn

+0

只是为了确保我在这里理解了所有内容:所以问题可能仍然存在,但是它会在索引之后“自行解决”重建? 我觉得我有一些阅读要做。 :) –

2

您的统计数据是否最新?缓存查询计划不正确的一个常见原因是过时的统计信息。

您是否有定期安排的索引重建工作?

+0

指标 - 可能。 Satatistics - 不知道。我没有建立数据库,所以我不得不仔细看看。感谢提示。 –