5.06 Examination dead lock 死锁检测
1 5.06 Examination dead lock 死锁检测
●一个事务申请锁而未获准,则进入等待,等 待其他事务释锁,以获得必须的数据资源 这就形成了事务间的等待关系。 。并发事务间出现循环等待时,如不加干预, 则会一直等待下去,叫死锁
2 ⚫ 一个事务申请锁而未获准,则进入等待,等 待其他事务释锁,以获得必须的数据资源. 这就形成了事务间的等待关系。 ⚫ 并发事务间出现循环等待时,如不加干预, 则会一直等待下去,叫死锁
。例: Tl T2 xlock(D1); 时 xlock(D2); 间 xlock(D2)月 等待 xlock(D1); 等待
3 ⚫ 例: 时间 T1 T2 . . . xlock(D1); . . . . . . . . . xlock(D2); 等待 . . . . . . . . . xlock(D2); . . . . . . . . . xlock(D1); 等待
。处理死锁方法有两种: 「检测死锁,发现后处理 防止死锁发生 -Examination of dead lock 死锁检测方法有两种: 1.超时法: 一个事务等待时间超过某一时限,则认为 它发生了死锁
4 ⚫ 处理死锁方法有两种: 检测死锁,发现后处理. 防止死锁发生. 一.Examination of dead lock 死锁检测方法有两种: 1.超时法: 一个事务等待时间超过某一时限,则认为 它发生了死锁
。优点:简单, ●问题: 1)死锁发生后, 需等待一定时间。 2)因通信受阻,系统负荷重等,等待超时的 事务,均被当死锁事务处理。 。注意:判定死锁发生的时限规定的太大,发现死 锁时间滞后太多;规定太短,则误判率太高,一 般须经过当前系统运行实验,才能确定
5 ⚫ 优点:简单. ⚫ 问题: 1)死锁发生后, 需等待一定时间。 2)因通信受阻,系统负荷重等,等待超时的 事务,均被当死锁事务处理。 ⚫ 注意:判定死锁发生的时限规定的太大,发现死 锁时间滞后太多;规定太短,则误判率太高,一 般须经过当前系统运行实验,才能确定
2.wait-for graph 等待图法 ·等待图是一个有向图 G=(W,V),其中: W:顶点集合: (Ti T1是数据库系统中当前运行的事务1,2,,n} V:边集合:{(Ti,Tj)/Tj等待Ti,且i<◇j} DBMS根据申请和加锁情况动态维护一个等待图 。当且仅当图中出现有向图回路时,死锁发生
6 2.wait-for graph 等待图法 ⚫ 等待图是一个有向图 G=(W,V),其中: W:顶点集合: {Ti Ti是数据库系统中当前运行的事务1,2,...,n} V:边集合:{(Ti,Tj)/Tj等待Ti,且i<>j} ⚫ DBMS根据申请和加锁情况动态维护一个等待图. ⚫ 当且仅当图中出现有向图回路时,死锁发生
。可以及时检测出死锁。 每发生一次等待事件,均要维修一次等待图, 检测一次死锁,花费大,影响系统性能。 ·较合理的办法是周期性检测死锁 。根据:等待事件在一般系统中不是频繁出现 的,因循环等待而死锁,则更是小概率事件! 不必频繁检测
7 ⚫ 可以及时检测出死锁。 ⚫ 每发生一次等待事件,均要维修一次等待图, 检测一次死锁,花费大,影响系统性能。 ⚫ 较合理的办法是周期性检测死锁, ⚫ 根据:等待事件在一般系统中不是频繁出现 的,因循环等待而死锁,则更是小概率事件, 不必频繁检测
死锁检测周期愈长,检测代价 。} 愈小;但因死锁不被及时发现 而致的损失却越大,可用实验方 法针对特定系统确定个最佳值。 代价 ↑检测代价 因死锁不被及时发现而致的损失 检测周期 最佳检测周期
8 ⚫ 死锁检测周期愈长,检测代价 愈小;但因死锁不被及时发现, 而致的损失却越大,可用实验方 法针对特定系统确定个最佳值。 代价 检测代价 因死锁不被及时发现而致的损失 检测周期 最佳检测周期
死锁发现后,DBMS一般处理方式如下: 1).在循环等待事务中选一个作为牺牲者 (victim) 2).卷回栖牲的事务,释放其获得的所有锁 及其他资源. 3).将释放的锁分配给等待它的事务
9 死锁发现后,DBMS 一般处理方式如下: 1).在循环等待事务中选一个作为牺牲者 (victim); 2).卷回牺牲的事务,释放其获得的所有锁 及其他资源. 3).将释放的锁分配给等待它的事务
Restart transaction (重启动事务) 对牺牲事务处理方式有二种: 。发消息给相关用户: 事务因死锁被撤消,用户向系统再交付该事务。 由DBMS重启动该事务。 但应注意,被牺牲者,要等待一段时间再重启 动,以防止重新死锁。甚至陷入:交付->死锁;再 交付->再死锁的恶性循环中. 10
10 Restart transaction (重启动事务) 对牺牲事务处理方式有二种: ⚫ 发消息给相关用户: 事务因死锁被撤消,用户向系统再交付该事务。 ⚫ 由DBMS重启动该事务。 但应注意,被牺牲者,要等待一段时间再重启 动,以防止重新死锁。甚至陷入:交付->死锁;再 交付->再死锁的恶性循环中