第7章事务管理.ppt

7.9 死锁的检测处理和防止 死锁：循环等待，谁也无法得到全部资源。 活锁：虽然其它事务都在有限长的时间内释放了资源，但某事务就是无法得到想要的资源。 X_lock R1 ┇ X_lock R2 wait TA X_lock R2 ┇ X_lock R1 wait TB R T1: S-lock T2: S-lock ┇ T: x-lock 活锁较简单，只需稍加修改调度策略，如FIFO 死锁：(1)防(不允许发生)；(2)治(允许，能消除) 死锁的检测 超时法: 某事务等待时间超过某个定值，便认为发生了死锁，该事务被终止。 等待图法 G=V,E V — 事务集 {Ti|Ti is a transaction in DBS (i=1,2,…n)} E － {Ti,Tj|Ti waits for Tj (i ≠ j)} 若图中有环路则说明已经发生死锁。 何时检测? 一旦某个事务等待. 周期性进行 死锁的处理 如何处理死锁? 选出牺牲事务(最年轻、卷回代价最小…) 终止牺牲事务释放它所有的锁及资源 该事务等待一段时间 重启动该事务(系统进行 or 用户进行) 死锁的防止 一次性申请所有锁 将数据对象编号，按序号加锁 一旦冲突，便终止相关事务 卷回重执 每个事务有唯一的时标.若在TA在某个已被TB加锁的数据对象上申请锁，采用下面的一种策略: 等待-死亡（Wait-die）: 若TA比TB老，TA等待 ，否则 TA“死亡”， i.e. 隔一段时间， TA 将重运行（仍用原时间标记） 击伤-等待（Wound-wait）:若TA比TB年轻，TA等待 ，否则，TA “击伤” TB, i.e. TB 被终止，隔一段时间，将重运行（仍用原时间标记） 上述方法中，都只有一个方向的等待，年老→ 年轻或年轻→年老，所以不会出现循环等待，从 而避免了死锁的发生。 7.10 多粒度封锁 Lock Granularities 多级封锁：从减少lock开销来讲，封锁单位越大越好；从提高事务运行并发度来讲，粒度越小越好。 所以大数据库中封锁单位分几级： DB－File－Record－Field In this situation, if a transaction acquires a lock on a node then it acquires implicitly the same lock on each descendant of that node. 所以多级封锁有两种锁法： Explicit lock Implicit lock 意向锁 如何检查implicit locks？ IBM的intention lock：提供IS、IX和SIX三种意向锁。例如低级某对象加了S锁，则在它所属的高级各对象上加IS锁，作为警告信息。这样在高级某对象上要加X锁时，就可以发现隐含的冲突。 IS－Intention share lock IX－Intention exclusive lock SIX－S＋IX DB File Record Field S IS IS 加锁原则： Locks are requested from root to leaves and released from leaves to root. record file DB (1) S IS IS (2) X IX IX (3) All read and some write SIX IX, IS 加锁顺序 对要写的record加X锁 以强代弱 DB File Record Field 例： 多级封锁时的相容矩阵： 待加 已有 NL IS IX S SIX X NL Y Y Y Y Y Y IS Y Y Y Y Y N IX Y Y Y N N N S Y Y N Y N N SIX Y Y N N N N X Y N N N N N X SIX IX S IS NL 强 弱 排他性 加锁时可以以强(排他性)代弱，但不能以弱代强。 7.6 失效的类型及恢复的对策 一种恢复方法通常只对某些类型的失效有用。 通常的失效可以分为以下三类： 1.事务失效(transaction failure) 事务应不可预知的原因而夭折。 例如：数据库中没有要访问的数据、输入数据类型不对、除数为零等。 事务失效时DB未被破坏，系统控制在手。且事务失效 一定发生在事务提交前。 恢复措施： MM丢弃该事务的消息队列； 如果需要，进行undo操作； 从ATL删除该事务的TID，释放该事务所占资源。 2.系统失效(system failure) 系统(包括OS和DBMS)崩溃，需要重新启动(restart)，DB未