存储过程在特定用户上失败

Question

我有一个存储过程经常失败，错误消息“Timeout expired”在特定用户上。

所有其他用户都可以很好地调用sp，甚至我可以使用查询分析器正常调用sp，只需10秒即可完成。但是，对于有问题的用户，日志显示ASP总是挂起大约5分钟，然后以超时中止。

我从ASP页面调用像这样“EXEC SP_TV_GET_CLOSED_BANKS_BY_USERS '006111'”

有人知道如何诊断问题？我已经试着在数据库中查看死锁，但没有找到任何。

谢谢，

Answer 1

我想回答你的问题，我们可能需要更多的信息。

例如，您是否使用Active Directory来验证您的用户？你使用SQL分析器进行调查吗？这听起来像是一个身份验证问题，SQL Server在验证这个特定用户时遇到问题。

Answer 2

听起来好像死锁问题​​..

还要确保此用户具有执行权限和读取SQL Server中

权利，但如果当时信息被写入其试图将因为交易尚未提交，因此读取您将会死锁。

杰夫做了一个伟大的职位，关于他的经验和stackoverflow。 http://www.codinghorror.com/blog/archives/001166.html

Answer 3

几件事情要检查：

1. 这是否是特定用户的机器上只发生？他可以尝试从另一台 机器吗？ - 这可能是一个客户端配置问题。
2. 您可以捕获该特定用户运行的实际字符串并从ASP页面运行它吗？可能是用户以一种产生循环或大量数据的方式执行SP。
3. 最后，如果您使用的是组织内应用程序，则可能是您的特定用户的权限与其他用户的权限不同。您可以在Active Directory级别比较它们。

现在，我可以推荐一款商业软件，它肯定能够解决您的问题。它记录了端到端的交易，并分析了特定的故障。但我不想在这个论坛上做广告。如果你愿意，给我留个便条，我会解释更多。

Answer 4

嗯，我可以建议你使用SQL Server Profiler并打开一个新的会话。从ASP页面调用存储过程，看看发生了什么。虽然这可能无法解决您的问题，但它肯定可以为您提供一个开始对自己进行“调查”的起点。

Answer 5

一些想法...

阅读注释表明，参数嗅探是导致该问题。

• 对于其他用户来说，高速缓存的计划是为他们发送
• 该用户的参数不够好，高速缓存的计划很可能是错的

如果该用户已经远远这可能发生更多的行比其他用户，或具有行与另一个表（因此不同的表/索引查找/扫描会更好）

为了测试参数嗅探：

• 在呼叫或def中使用RECOMPILE（暂时）。对于复杂查询，这可能会很慢
• 在超时后重建索引（或仅统计数据），然后重试。这会使所有缓存计划

要解决： 面膜参数

DECLARE @MaskedParam varchar(10) 
SELECT @MaskedParam = @SignaureParam 

SELECT...WHERE column = @MaskedParam 

不仅仅是谷歌“参数嗅探”和“参数屏蔽”