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

发布于 2024-07-08 17:30:29 字数 302 浏览 6 评论 0原文

我有一个存储过程在特定用户上不断失败,并显示错误消息“超时已过期”。

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

我从 ASP 页面调用,如下所示“EXEC SP_TV_GET_CLOSED_BANKS_BY_USERS '006111'

有人知道如何诊断问题吗? 我已经尝试过查看数据库中的死锁,但没有发现任何死锁。

谢谢,

I have a Stored Procedure that is constantly failing with the error message "Timeout expired," on a specific user.

All other users are able to invoke the sp just fine, and even I am able to invoke the sp normally using the Query Analyzer--it finishes in just 10 seconds. However with the user in question, the logs show that the ASP always hangs for about 5 minutes and then aborts with a timeout.

I invoke from the ASP page like so "EXEC SP_TV_GET_CLOSED_BANKS_BY_USERS '006111'"

Anybody know how to diagnose the problem? I have already tried looking at deadlocks in the DB, but didn't find any.

Thanks,

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

仅冇旳回忆 2024-07-15 17:30:29

一些想法...

阅读评论表明参数嗅探导致了问题。

  • 对于其他用户,缓存的计划对于他们发送的参数来说足够好
  • 对于该用户,缓存的计划可能是错误的

如果该用户的行数比其他用户多得多,或者在另一个表中拥有行数,则可能会发生这种情况(因此不同的表/索引查找/扫描会更好)

要测试参数嗅探:

  • 在调用或 def 中使用 RECOMPILE (临时)。 对于复杂的查询来说,这可能会很慢,
  • 在超时后重建索引(或只是统计数据),然后重试。 这会使所有缓存的计划无效

要修复:
屏蔽参数

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

SELECT...WHERE column = @MaskedParam

只需谷歌“参数嗅探”和“参数屏蔽”

Some thoughts...

Reading the comments suggests that parameter sniffing is causing the issue.

  • For the other users, the cached plan is good enough for the parameter that they send
  • For this user, the cached plan is probably wrong

This could happen if this user has far more rows than other users, or has rows in another table (so a different table/index seek/scan would be better)

To test for parameter sniffing:

  • use RECOMPILE (temporarily) on the call or in the def. This could be slow for complex query
  • Rebuild the indexes (or just statistics) after the timeout and try again. This invalidates all cached plans

To fix:
Mask the parameter

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

SELECT...WHERE column = @MaskedParam

Just google "Parameter sniffing" and "Parameter masking"

苦行僧 2024-07-15 17:30:29

我认为要回答您的问题,我们可能需要更多信息。

例如,您是否使用 Active Directory 来验证您的用户? 您是否使用过 SQL Profiler 进行过调查? 听起来这可能是一个身份验证问题,其中 SQL Server 在验证此特定用户时遇到问题。

I think to answer your question, we may need a bit more information.

For example, are you using Active directory to authenticate your users? Have you used the SQL profiler to investigate? It sounds like it could be an auth issue where SQL Server is having problems authenticating this particular user.

做个少女永远怀春 2024-07-15 17:30:29

在我看来,这像是一个死锁问题。

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

但是,如果当时在尝试读取信息时正在写入信息,那么您将死锁,因为事务尚未完成已承诺。

Jeff 发表了一篇很棒的文章,介绍了他在这方面的经验以及 stackoverflow。
http://www.codinghorror.com/blog/archives/001166.html

Sounds to me like a dead lock issue..

Also make sure this user has execute rights and read rights in SQL Server

But if at the time info is being written as its trying to be read you will dead lock, as the transaction has not yet been committed.

Jeff did a great post about his experience with that and stackoverflow.
http://www.codinghorror.com/blog/archives/001166.html

黎夕旧梦 2024-07-15 17:30:29

有几件事需要检查:

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

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

Couple of things to check:

  1. Does this happen only on that specific user's machine? Can he try it from another
    machine? - it might be a client configuration problem.
  2. Can you capture the actual string that this specific user runs and run it from an ASP page? It might be that user executes the SP in a way that generates either a loop or a massive load of data.
  3. Finally, if you're using an intra-organization application, it might be that your particular user's permissions are different than the others. You can compare them at the Active Directory level.

Now, I can recommend a commercial software that will definitely solve your issue. It records end-to-end transactions, and analyzes particular failures. But I do not want to advertise in this forum. If you'd like, drop me a note and I'll explain more.

夢归不見 2024-07-15 17:30:29

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

Well, I could suggest that you use SQL Server Profiler and open a new session. Invoke your stored procedure from your ASP page and see what is happening. While this may not solve your problem, it can surely provide a starting point for you to carry out some 'investigation' of your own.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文