背景:一个客服数据库,每天不定时死锁,死锁时间很短。等到远程时死锁已经结束。
起初遇到死锁,一般都是先通过活动监视器,找到头阻塞的id,通过spid定位到机器和程序。但是这次情况比较特殊,每次死锁时间较短,不好追踪。最后想来想去还是锁的概念掌握的不够清晰,在网上又找了几篇文章,受到了启发。
首先为什么会锁,是因为 1.A事务手里拿着M1 ,需要获得M2 ,B事务手里拿着M2,需要获得M2 2,A事务如果获得某张表的共享锁 S 不释放,B事务想要update 表 会锁 。 我感觉这个客户的情况像第二种:
该语句可以查看数据库中session锁情况。
SELECT resource_type, request_mode, resource_description,request_session_id, DB_NAME(resource_database_id)as resource_database FROM sys.dm_tran_locks WHERE resource_type <> 'DATABASE'
发现有一个spid一直使用架构锁,通过这个spid 再查询分析器里过滤出 是在执行一个存储过程,对一个表的索引重建。 这个应该会对数据库的性能影响很大,并如果有用户访问这张表会造成死锁。 查询分析器里可以看到应用名称和ip地址。结束这个应用服务。之后就是继续观察,希望这次猜的没问题。
标签:resource,数据库,sqlserver,死锁,spid,M2,心得,id From: https://www.cnblogs.com/A-little-bird/p/17481246.html