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重启动该事务。 但应注意,被牺牲者,要等待一段时间再重启 动,以防止重新死锁。甚至陷入:交付->死锁;再 交付->再死锁的恶性循环中
