数据库死锁

简介一、死锁的表现 1、错误信息是:事务(进程 ID)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。 2、错误信息是:事务(进程 ID )与另一个进程被死锁在 锁 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。请重新运行该事务。 二、死锁的原因 1、由于多用户、多任务的并发性和事务的完整性要求,当多个事务处理对多个资源同时访问时,若双方已锁定一部分资源但也都需要对方已锁定的资源时,无法在有限的时间内完全获得所需的资源,就会处于无限的等待状态,从而造成其对资源需求的死
一、死锁的表现
1、错误信息是:事务(进程 ID)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。
2、错误信息是:事务(进程 ID )与另一个进程被死锁在 锁 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。请重新运行该事务。

二、死锁的原因
1、由于多用户、多任务的并发性和事务的完整性要求,当多个事务处理对多个资源同时访问时,若双方已锁定一部分资源但也都需要对方已锁定的资源时,无法在有限的时间内完全获得所需的资源,就会处于无限的等待状态,从而造成其对资源需求的死锁。

2、数据库本身加锁机制的实现方法不同,各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11 中,最小锁为 2K一页的加锁方法,而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高,如应用系统中的系统配置表或系统参数表就属于此类表),被访问的频率高,就容易在该页上产生死锁。


表现一:
一个用户 A 访问表 A(锁住了表 A),然后又访问表 B。另一个用户 B 访问表 B(锁住了表 B),
然后企图访问表 A。这时用户 A 由于用户 B 已经锁住表 B,它必须等待用户 B 释放表 B,
才能继续,同样用户 B 要等用户 A 释放表 A 才能继续操作,这样就造成了死锁。
解决方法:
这种死锁是由于程序的 BUG 产生的,需调整程序对数据库层的实现逻辑。仔细分析程序的逻辑:
(1)尽量避免同时锁定两个资源。
(2)必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源。

表现二:
用户 A 读一条纪录,然后修改该条纪录,同时用户 B 也修改该条纪录。这里用户 A 的事务里锁的性质由共享锁企图上升到独占锁 (for update),而用户 B 里的独占锁由于 A 有共享锁存在所以必须等 A 释放掉共享锁,而 A 由于 B 的独占锁而无法上升的独占锁也就不可能释
放共享锁,于是出现了死锁。这种死锁比较隐蔽,但其实在稍大点的项目中经常发生。
解决方法:
让用户 A 的事务(即先读后写类型的操作),在 select 时就是用 update lock。
语法如下:select * from table1 with(updlock) where ….

上一篇:/p/python, perl

下一篇:异常ip

本文转自:https://blog.csdn.net/hexieshangwang/article/details/47189213
新加评论 评论标题: