谁帮我分析一下死锁日志？

如一宝宝 2013-01-13 11:32:28
既然是死锁，为何只等待了665毫秒？


<deadlock-list>

  <deadlock>

    <victim-list>

      <victimProcess id="process3e7f288" />

    </victim-list>

    <process-list>

      <process id="process3e7f288" taskpriority="0" logused="524" waitresource="RID: 9:1:5419:39" waittime="665" ownerId="1038620" transactionname="user_transaction" lasttranstarted="2013-01-11T21:09:40.887" XDES="0x82679950" lockMode="U" schedulerid="4" kpid="5700" status="suspended" spid="53" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2013-01-11T21:09:40.887" lastbatchcompleted="2013-01-11T21:09:40.887" clientapp=".Net SqlClient Data Provider" hostname="WIN-BD8F5B743NK" hostpid="5328" loginname="pa" isolationlevel="read committed (2)" xactid="1038620" currentdb="9" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">

        <executionStack>

          <frame procname="" line="20" stmtstart="756" stmtend="864" sqlhandle="0x0300090027261038ca540d012ca100000100000000000000" />

        </executionStack>

        <inputbuf>

Proc [Database Id = 9 Object Id = 940582439]    </inputbuf>

      </process>

      <process id="process3e5b048" taskpriority="0" logused="664" waitresource="RID: 9:1:7430:66" waittime="670" ownerId="1038633" transactionname="user_transaction" lasttranstarted="2013-01-11T21:09:40.890" XDES="0x80c9ce80" lockMode="S" schedulerid="2" kpid="3228" status="suspended" spid="73" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2013-01-11T21:09:40.890" lastbatchcompleted="2013-01-11T21:09:40.890" clientapp=".Net SqlClient Data Provider" hostname="WIN-BD8F5B743NK" hostpid="5328" loginname="pa" isolationlevel="read committed (2)" xactid="1038633" currentdb="9" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">

        <executionStack>

          <frame procname="" line="12" stmtstart="226" stmtend="754" sqlhandle="0x0300090027261038ca540d012ca100000100000000000000" />

        </executionStack>

        <inputbuf>

Proc [Database Id = 9 Object Id = 940582439]    </inputbuf>

      </process>

    </process-list>

    <resource-list>

      <ridlock fileid="1" pageid="5419" dbid="9" objectname="" id="lock819f0980" mode="X" associatedObjectId="72057594086096896">

        <owner-list>

          <owner id="process3e5b048" mode="X" />

        </owner-list>

        <waiter-list>

          <waiter id="process3e7f288" mode="U" requestType="wait" />

        </waiter-list>

      </ridlock>

      <ridlock fileid="1" pageid="7430" dbid="9" objectname="" id="lock80b92200" mode="X" associatedObjectId="72057594086096896">

        <owner-list>

          <owner id="process3e7f288" mode="X" />

        </owner-list>

        <waiter-list>

          <waiter id="process3e5b048" mode="S" requestType="wait" />

        </waiter-list>

      </ridlock>

    </resource-list>

  </deadlock>

</deadlock-list>
...全文
249 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
KevinLiu 2013-01-14
  • 打赏
  • 举报
 回复
引用 8 楼 lowson0 的回复:
引用 7 楼 perfectaction 的回复:spid53 : waitresource="RID: 9:1:5419:39" 可以看出databaseid=9 文件号是1 页号是5419 行号是39 此操作被牺牲 spid73 : waitresource="RID: 9:1:7430:66" 可以看出databaseid=9 文件号是1 页号是7430 行号是……
看一下这个： <ridlock fileid="1" pageid="5419" dbid="9" objectname="" id="lock819f0980" mode="X" associatedObjectId="72057594086096896"> <owner-list> <owner id="process3e5b048" mode="X" /> </owner-list> <waiter-list> <waiter id="process3e7f288" mode="U" requestType="wait" /> </waiter-list> </ridlock> <ridlock fileid="1" pageid="7430" dbid="9" objectname="" id="lock80b92200" mode="X" associatedObjectId="72057594086096896"> <owner-list> <owner id="process3e7f288" mode="X" /> </owner-list> <waiter-list> <waiter id="process3e5b048" mode="S" requestType="wait" />
如一宝宝 2013-01-14
  • 打赏
  • 举报
 回复
引用 7 楼 perfectaction 的回复:
spid53 : waitresource="RID: 9:1:5419:39" 可以看出databaseid=9 文件号是1 页号是5419 行号是39 此操作被牺牲 spid73 : waitresource="RID: 9:1:7430:66" 可以看出databaseid=9 文件号是1 页号是7430 行号是66 能过select SELECT DB_……
select出来的S锁难道不会在获取资源后释放? 我两个事务都是行上面的S锁吧?
nzperfect 2013-01-14
  • 打赏
  • 举报
 回复
spid53 : waitresource="RID: 9:1:5419:39" 可以看出databaseid=9 文件号是1 页号是5419 行号是39 此操作被牺牲 spid73 : waitresource="RID: 9:1:7430:66" 可以看出databaseid=9 文件号是1 页号是7430 行号是66 能过select SELECT DB_NAME(9)可以得到你的库名，然后 然后通过下面得到表名和索引名： use 你的库名 go SELECT OBJECT_NAME(i.object_id), i.name FROM sys.partitions AS p INNER JOIN sys.indexes AS i ON i.object_id = p.object_id AND i.index_id = p.index_id WHERE p.partition_id = 72057594086096896 executionStack / inputbuf 都没有给出具体的SQL语句，可能需要profiler去捕获一下 不过从上面这些信息看起来，你的相关的表没有聚集索引，这肯定是一个问题，如果索引再不合适，这样无论是update/delete数据操作行数多时，就可能死锁。
如一宝宝 2013-01-14
  • 打赏
  • 举报
 回复
引用 5 楼 Haiwer 的回复:
搞什么，贴的同一个问题的连接，会死锁的
http://bbs.csdn.net/topics/390345833 不好意思,帖错了.
昵称被占用了 2013-01-14
  • 打赏
  • 举报
 回复
搞什么，贴的同一个问题的连接，会死锁的
如一宝宝 2013-01-14
  • 打赏
  • 举报
 回复
引用 3 楼 Haiwer 的回复:
这种互相等待的死锁，等待多少时间也不会自动解开，所以一旦死锁检测进程运行发现，就直接报死锁，不必等到死锁时间到
http://bbs.csdn.net/topics/390345786 你好,谢谢你的解答,这也是我发的帖子.能否帮我看看?
昵称被占用了 2013-01-14
  • 打赏
  • 举报
 回复
这种互相等待的死锁，等待多少时间也不会自动解开，所以一旦死锁检测进程运行发现，就直接报死锁，不必等到死锁时间到
昵称被占用了 2013-01-14
  • 打赏
  • 举报
 回复
要查出两个进程的语句 这两个进程都需要更新objectid 72057594086096896的同一个页数据，互相等待，形成了死锁，而且没有涉及其他对象，很可能是锁提示使用不当引起的（比如select with xlock）
以学习为目的 2013-01-14
  • 打赏
  • 举报
 回复
都有一定的解死锁机制的，一般的锁，内部会自行解锁或释放。至于你所谓的死锁，也有可能是假死
昵称被占用了 2013-01-14
  • 打赏
  • 举报
 回复
SELECT TOP 1 UserQuestId FROM quest.UserQuests 改为 SELECT TOP 1 UserQuestId FROM quest.UserQuests with (nolock) 看看 两个语句是否调换次序看不出来，这个逻辑不好理解，没有开事务估计与次序关系不大 另外，如果没有聚集索引是有较大问题的，楼上大叔已经提到过
如一宝宝 2013-01-14
  • 打赏
  • 举报
 回复
引用 11 楼 perfectaction 的回复:
如果你对锁这块一点都不了解的话，还是先查下资料吧。 你的问题表面上看就是缺聚集索引，再者就是可能非聚集索引也不合适。

CREATE PROCEDURE [quest].[UserQuests_Delete]
(
@UserId INT,
@QuestId INT
)
  
AS
BEGIN
SET NOCOUNT ON
  
DELETE FROM
    quest.UserQuests
WHERE
UserId=@UserId AND
QuestId= @QuestId AND
UserQuestState=2 AND
UserQuestId<>(SELECT TOP 1 UserQuestId FROM quest.UserQuests WHERE UserId=@UserId AND QuestId= @QuestId AND UserQuestState=2 ORDER BY CreateDateUTC DESC)
  
DELETE FROM quest.UserQuests WHERE  UserQuestState=3
END
这是我的存储过程,我将两句话换个位置是不是会好点?
nzperfect 2013-01-14
  • 打赏
  • 举报
 回复
如果你对锁这块一点都不了解的话，还是先查下资料吧。 你的问题表面上看就是缺聚集索引，再者就是可能非聚集索引也不合适。
nzperfect 2013-01-14
  • 打赏
  • 举报
 回复
引用 8 楼 lowson0 的回复:
select出来的S锁难道不会在获取资源后释放? 我两个事务都是行上面的S锁吧?
下面这两个表明一个是S，一个是X，你删除时是由S转向X的，当索引不当或者碎片多时都会有死锁。 <owner id="process3e7f288" mode="X" /> <waiter id="process3e5b048" mode="S" requestType="wait" />
MySQL 之 死锁日志的查看和分析
MySQL死锁日志分析
mysql死锁日志查看方法
它会输出大量的内部信息，内容分为很多小段，每一段对应 innodb 存储引擎不同部分的信息，其中 LATEST DETECTED DEADLOCK 部分显示的最近一次的死锁信息。从死锁日志中可以看到关联的两个事务相关信息，当一个事务持有了其他事务需要的锁，同时又想获得其他事务持有的锁时，等待关系上就会产生循环，Innodb 不会显示所有持有和等待的锁，但死锁日志也显示了相关的信息来帮你确定，排查死锁发生的索引，这对于你确定能否避免死锁有较大的价值。本篇文章我们一起来看下 MySQL 的死锁日志。
MySQL死锁日志的查看和分析
目录 一，关于MySQL的死锁 二，人造一个死锁的场景 三，查看最近一次死锁的日志 四，死锁日志的内容 1，事务1信息 2，事务1持有的锁 3，事务1正在等待的锁 4，事务2信息 5，事务2正在持有的锁 6，事务2正在等待的锁 7，死锁处理结果 五，关于mysql的八种锁 1，行锁（Record Locks） 2，间隙锁（Gap Locks） 3，临键锁（Next-key Locks） 4，共享锁/排他锁（Shared and Exclusive Locks） 5，意向共享
mysql死锁以及死锁日志分析
转自 ：https://www.toutiao.com/a6584762452099990030/?tt_from=mobile_qq&amp;utm_campaign=client_share&amp;timestamp=1533169309&amp;app=news_article&amp;utm_source=mobile_qq&amp;iid=39055545733&amp;utm_med...
mysql 死锁日志_【MySQL】如何阅读死锁日志
一 前言工欲善其事必先利其器，前面分析了很多死锁案例，并没有详细的介绍如何通过死锁日志来诊断死锁的成因。本文将介绍如何读懂死锁日志，尽可能的获取信息来辅助我们解决死锁问题。二 日志分析2.1 场景为了更好的学习死锁日志，我们需要提前了解死锁场景MySQL 5.6 事务隔离级别为RRCREATE TABLE `ty`(`id`int(11)NOTNULL AUTO_INCREMENT,`a`int(...
疑难问题

22,209

社区成员

121,730

社区内容

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章