【发布时间】:2017-06-18 03:37:16
【问题描述】:
我读过这个死锁问题当数据库表开始累积数千行并且许多用户开始同时处理同一个表时,表上的 SELECT 查询开始产生锁争用和事务死锁。
这个死锁问题是否与 TransactNo updlock 有关? 如果你知道这个问题,请告诉我。 提前致谢。
【问题讨论】:
标签: sql-server sql-server-2005
我读过这个死锁问题当数据库表开始累积数千行并且许多用户开始同时处理同一个表时,表上的 SELECT 查询开始产生锁争用和事务死锁。
这个死锁问题是否与 TransactNo updlock 有关? 如果你知道这个问题,请告诉我。 提前致谢。
【问题讨论】:
标签: sql-server sql-server-2005
发生死锁的原因有很多,有时解决死锁问题更像是一门艺术,而不是一门科学。
除了普通的 SQL Profiler 之外,我用来查找和消除死锁的工具是一个轻量级工具,它可以在死锁发生时以图形方式描述死锁。当您看到死锁时,您可以向下钻取并获取有价值的信息。死锁检测器 -- http://www.sqlsolutions.com/products/sql-deadlock-detector
这是一个简单的工具,但对我来说,它完全可以做它应该做的事情。有一件事:我第一次使用它时,我不得不等待 15 分钟,以便该工具收集足够的指标以开始显示死锁。
【讨论】:
高隔离的一个常见问题是由于以下情况导致的锁升级死锁;即(其中 X 是任何资源,例如一行)
死锁!这种情况可以通过更多个锁来避免:
(UPDLOCK) 的 X - 获得排他锁【讨论】:
发生死锁的原因有很多,因此如果您想获得帮助并告诉我们导致死锁的原因,您必须先做一些功课,即。执行死锁时涉及哪些批次,涉及哪些资源等等。 Profiler deadlock event graph 始终是开始调查的好地方。
如果我在黑暗中冒险一试,会发生什么情况是您的查询和索引未正确调整,因此您的大多数读取操作(可能还有一些写入操作)都是全表扫描,因此可以保证与更新。这可能导致deadlocks by order of index access、操作顺序死锁、升级死锁等等。
一旦您确定了死锁的原因,就可以采取适当的措施来消除它。采取脏读的正确做法极为罕见。
顺便说一句,我不确定您所说的“TransactNo updlock”是什么意思。你是专门问S-U/U-S asymmetry of the U locks吗?
【讨论】:
您没有提供足够的信息来直接回答您的问题。
但大多数锁定和阻塞可以通过使用“正确”索引来覆盖您的查询工作负载来减少(甚至消除)。
由于您安排了定期索引维护工作吗?
如果您的 SELECTs 不需要 100% 准确(即允许脏读等),那么您可以运行一些 SELECTS 和 WITH(NOLOCK),这与 READ UNCOMMITED 的隔离级别相同.请注意:我并不是建议您将WITH(NOLOCK) 放在任何地方;只针对那些不需要 100% 完整数据的 SELECTS。
【讨论】:
我将把我自己的文章和帖子加入到有关死锁的组合中:
https://www.sqlskills.com/blogs/jonathan/category/deadlock/
我在 JumpstartTv.com 上也有一系列解决死锁问题的视频:
http://jumpstarttv.com/profiles/1379/Jonathan-Kehayias.aspx
死锁可能很难解决,但除非您发布死锁图表信息,否则我们只能提供帖子链接和解决死锁的信息。
【讨论】: