SQL Server 2000 - 调试死锁
我正在寻找有关如何调试和解决 SQL Server 2000 数据库中的死锁问题的建议。 有人建议我使用跟踪标志 1024 和 3605，我发现它们给了我以下信息：
1024 - 此跟踪标志返回参与死锁的锁的类型以及受影响的当前命令。
3605 - 此跟踪标志将跟踪输出发送到错误日志。
仍然需要发现特定的存储过程、表和索引，因此目标是使用这些跟踪标志来执行此操作。 然后从那里我将更好地了解哪些索引需要调整、调整查询的锁定提示以及需要修复的潜在存储过程错误。
对于将这一切归咎于共同问题，还有其他建议或幸福结局的战争故事吗？
I'm looking for suggestions on how to debug and chase down deadlock issues in an SQL Server 2000 database. I've had it recommended to me to use trace flags 1024 and 3605, which I have found give me the following:
1024 - this trace flag returns the type of locks participating in the deadlock and the current command affected.
3605 - this trace flag sends trace output to the error log.
The specific stored procedures, tables and indexes still need to be uncovered, so the goal is to use these trace flags to do so. And then from there I'll know better what indexes need tuning, locking hints for tuning queries, and potential sproc bugs to fix.
Any other suggestions or happy ending war stories on chasing down this all to common problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一旦了解了所涉及的sql语句，代码分析肯定会有所帮助。 一些经验规则包括检查访问行的顺序以及检查用于 SQL 语句的隔离级别。 分析器跟踪可以提供很大帮助。
大多数时候，这是因为读取器试图获取由写入器独占锁定的资源的共享锁。
Once you know the sql statements involved, a code analysis will surely help. Some thumb rules are checking for the order in which the rows are accessed and checking for the isolation level used for the SQL statements. A profiler trace can help a lot.
Most of the time, it is because of a reader trying to get a shared lock on a resource locked exclusively by a writer.