两个事物 update同一张表出现的死锁问题

引言


近来做省一级计算机一级考试系统的时候,学生端进行大批量判分的时候,出现了这样的问题(事务(进程 ID 262)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。):



这个就是我们在代码中写了大批量的update语句,用trace Profiler ,我们对死锁追踪是这样的:



分析:


我们来分析一下上面的图,上面为DeakLock graph,图中左右两边的椭圆形相当于一个处理节点(Process Node),当鼠标移动到上面的时候,可以看到内部执行的代码,如update,Insert,Delete等等,有打叉的左边的椭圆形就是牺牲者,没有打叉的为优胜者。中间两个长方形就是一个资源节点(Resource Node),描述数据库中的对象,如一个表、一行或者一个索引。在我们当前的实例中,描述的是:假设左边的椭圆形为Process Node1,右边的椭圆形为Process Node2,上面的长方形为Resource Node1,下面为Resource Node2,Process Node1对Resource Node1申请一个U锁,但是,Resource Node1被Process Node2的X锁占有;另一边,Process Node2对Resource Node2申请一个U锁,但是Resource Node2被Process Node2的X锁占有。这样就形成了一个资源占有的死循环,这个时候,sql server会在sq_lock中检测到死锁,这个时候,就会出现一个牺牲品的事情,以至于系统能够继续运行。


我们可以看一下,两个事务分为什么:


### 数据库死锁操作系统死锁的区别 数据库死锁特指多个事务在获取资源时形成循环依赖,导致各事务无限期等待其他事务释放资源的情况。而操作系统中的死锁涉及更广泛的系统资源竞争问题,不仅限于内存或磁盘空间等硬件资源的竞争,还包括进程间通信、文件句柄等多种类型的资源争用。 #### 资源类型差异 - **数据库环境下的死锁** 主要围绕着记录级别的定展开,即不同事务试图同时更新同一组数据行却互不相让的情形更为常见[^1]。 - **操作系统层面的死锁** 则可能涉及到CPU时间片分配、I/O设备使用权等多个方面的问题,其范围远超出了单一应用程序内部的数据交互范畴[^2]。 ### 解决方案对比 对于两种环境中出现的死锁现象,尽管具体实现细节有所区别,但基本思路相似——预防为主,辅以必要的检测和恢复手段: #### 预防措施 - 在数据库管理中,可以通过规定统一的事物执行路径来避免潜在的环形等待链;调整合适的隔离级别也有助于缓解因频繁读写冲突引发的僵局风险[^3]。 - 对于操作系统而言,则强调合理规划任务调度算法,确保各类请求按照既定优先级有序处理,从而最大限度地规避不必要的资源争夺局面的发生。 #### 检测机制 一旦预防措施未能奏效,及时发现并妥善处置已形成的死锁至关重要: - 大多数现代关系型数据库产品内置有自动化的死锁监测工具,在探测到异常状况后会择牺牲某个受害方(通常是持有最少资源的那个)以便打破恶性循环,并通知应用层采取补偿行动重新提交失败的操作。 - 类似地,某些高级别的实时多任务操作系统同样具备类似的自我修复能力,不过由于应用场景更加复杂多样,因此往往还需要借助额外的日志分析或者外部监控程序来进行辅助判断。 ```sql -- 这是一个简单的SQL语句用于展示如何设置事务隔离级别以防止死锁 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN TRAN; UPDATE Accounts SET Balance = Balance - 100 WHERE AccountID = 'A'; WAITFOR DELAY '00:00:05'; -- Simulate delay that might cause deadlock UPDATE Accounts SET Balance = Balance + 100 WHERE AccountID = 'B'; COMMIT TRAN; ```
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值