实例分析数据库死锁的产生与发展,实例分析数据库死锁的产生与处理

  实例分析数据库死锁的产生与发展,实例分析数据库死锁的产生与处理

  最近在系统运行过程中,会提示“该事务(进程ID 54)被另一个进程锁定,已被选为死锁牺牲品。请重新运行交易。

  以前也发生过,但我不知道从何说起。朱总经理建议,所有与该表相关的sql语句都要围绕错误语句访问的表进行查找,看是否会造成死锁。其实听到这个提示的时候,脑子也是一片混乱。后来看到牺牲的sql语句有三个表,而且是最常用的三个表。按照朱的想法工作量有多大?另外,我对数据库死锁的一些细节还有点不清楚。这不是大海捞针吗?

  第二天,我想了一个办法,先重现这个死锁,然后通过数据库找到死锁前后的sql,这样范围就小了很多(我不敢肯定我还能了解死锁的细节,当然这是事先没有预料到的)。

  照你说的做就行了,第一步就是重现僵局。就在很久以前,写了一个机器人来测试这个系统的并发性,可以模仿多个客户端做常规操作。但是有些天没更新了,修改了2个小时左右。最后运行,还不错,可以用。18机器人做常规操作,我在客户端做非常规操作。客户端一停止,我就运行exec sp_who_lock。

  手工排序后,如下图:

  54被86阻止更新Sale _ Object Set objstateid=@ objstateid

  1,76,86,101被54 select * from sale _ objstate,sale _ object,sale _ subsvc阻止

  60、66被71更新Sale _ Object Set objstateid=@ objstateid阻止

  理解“独占锁X”和“共享锁S”的含义可以总结如下:“”

  - select在ReadCommitted事务中添加共享锁,在RepeatableRead事务中添加排他锁;

  -在插入、更新和删除期间始终应用排他锁;

  - update必须等待select事务释放共享锁并将其转换为独占锁,然后才能执行;

  -如果事务T将S锁添加到数据对象A,其他事务只能将S锁添加到A,而不能添加X锁,直到T释放A上的S锁。

  并在调用上面的相关sql语句之前查询代码中的语句,结论如下:

  -86号流程已重新提交

  86插入SALE_ObjState以获得SALE_ObjState的独占锁

  86 select SALE_ObjState持有独占锁

  8更新需要SALE_Object的独占锁。

  -54号过程可重复读取

  54 select * from SALE_SubSvc,SALE_Object,SALE_ObjState

  依次获取sale _ subsvc和sale _ object的独占锁,但是需要SALE_ObjState的独占锁,但是被86占用,无法获取(这里是我自己根据sql中的from语句依次获取表的锁,因为作为一个程序,不可能同时锁定三个表,必须逐个添加,所以……)

  过程71的过程与过程86的过程相同(此处省略)

  因为进程54使用了更高级别的事务,这也是死锁的关键点。

  解决方案:

  1.如果程序中54个进程的查询不需要使用RepeatableRead transaction,那么将其修改为ReadCommitted transaction。

  2.如果程序中必须使用RepeatableRead事务,必须通过改变sql语句SELECT * FROM SALE _ SUSBVC,SALE_Object和SALE_ObjState中SALE _ object和SALE _ objstate的顺序来实现。但这种交换也是有风险的,因为你不知道是否还有其他地方会出现死锁。这个解比较复杂,理论上很难详细讨论。

  本文的目的是让读者了解数据库死锁的一些细节。如果有不清楚的描述,请指出来,我一定会回答。

  由于我的水平是菜鸟水平,如果理解不正确请指正!

实例分析数据库死锁的产生与发展,实例分析数据库死锁的产生与处理