第17讲事务并发控制讲述.ppt

* * * * * * * * * * * * * * * 产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。 预防死锁的发生就是要破坏产生死锁的条件 * * * 活锁和死锁的只是一放在等待，不是循环等待，会影响系统性能。 * 在讨论加锁协议时一直没有讨论被加锁的数据对象究竟是什么。 封锁的对象是元组的话称为行级锁，封锁的对象是关系的话称为表级锁。比如表级锁的粒度就比行级锁要大。封锁的粒度对于系统的并发度和系统开销密切相关。 那么系统究竟应该提供多大的封锁粒度比较合适呢？ * 例若封锁粒度是表，事务T1需要修改元组S2，则T1必须对包含L1的整个数据页A加锁。如果T1对A加锁后事务T2要修改A中元组L2，则T2被迫等待，直到T1释放A。如果封锁粒度是元组，则T1和T2可以同时对L1和L2加锁，不需要互相等待，提高了系统的并行度。 那么一个系统究竟提供多大的封锁粒度比较合适呢？维护锁的开销。 * 需要处理大量元组的事务可以以关系为封锁粒度，需要处理多个关系的大量元组的事务可以以数据库为封锁粒度，而对于一个处理少量元组的用户事务，以元组为封锁粒度比较合适。 事务T需要读取整个表，若封锁粒度是元组，T必须对表中的每一个元组加锁，开销极大 为了在并发度和系统开销之间得到一个比较好的平衡，数据库管理系统通常会提供多种粒度供事务选择。 * 究竟一个事务应该封锁粒度，是由事务的实际需求决定。现代大型rdbms一般均支持多粒度加锁。而在微型计算机的RDBMS中，由于并发要求不高，一般以表作为加锁单位，且不提供其他粒度的锁，称为单粒度加锁。 需要处理多个关系的大量元组的用户事务：以数据库为封锁单位 需要处理大量元组的用户事务：以关系为封锁单元 只处理少量元组的用户事务：以元组为封锁单位 * 我们可以把系统支持的各种封锁对象用树形结构描述出来称为多粒度树。 * 根结点为数据库，数据库的子结点为关系，关系的子结点为元组。 可以将整个数据库比喻为一间教室，教室被走廊分成几个块，每一块比作为一张表，每一块的每一排看成是元组。 * 我们可以把系统支持的各种封锁对象用树形结构描述出来称为多粒度树。 * 由于隐式锁和多级封锁粒度的存在，使得加锁时进行的锁冲突检查比较困难。 系统检查封锁冲突时 要检查显式封锁 还要检查隐式封锁对某个数据对象加锁，系统要检查 该数据对象 有无显式封锁与之冲突 所有上级结点 检查本事务的显式封锁是否与该数据对象上的隐式封锁冲突：(由上级结点已加的封锁造成的） 所有下级结点 看上面的显式封锁是否与本事务的隐式封锁（将加到下级结点的封锁）冲突 如果希望对“多粒度”树中的某个节点加锁，则需要在该节点的所有祖先节点和后裔节点都进行锁的相容性检查，这样检查效率很低。 * 例如：事务T1要对关系R1加S锁 要首先对数据库加IS锁 检查数据库和R1是否已加了不相容的锁(A或IA) 不再需要搜索和检查R1中的元组是否加了不相容的锁(A锁) 系统检查封锁冲突时 要检查显式封锁 还要检查隐式封锁对某个数据对象加锁，系统要检查 该数据对象 有无显式封锁与之冲突 所有上级结点 检查本事务的显式封锁是否与该数据对象上的隐式封锁冲突：(由上级结点已加的封锁造成的） 所有下级结点 看上面的显式封锁是否与本事务的隐式封锁（将加到下级结点的封锁）冲突 多粒度封锁 具有意向锁的多粒度封锁方法 申请封锁时应该按自上而下的次序进行 释放封锁时则应该按自下而上的次序进行 事务的并发控制 数据库 关系Rn 关系R1 元组1 元组n 元组n 元组1 …… …… …… 加锁 解锁 数据库 关系Rn 关系R1 元组1 元组 元组n 元组 …… …… …… 事务T 欲加X锁 有无封锁 有无封锁 有无封锁 (S) 事务的并发控制 数据库 关系Rn 关系R1 元组1 元组 元组n 元组 …… …… …… 事务T1 (IS) (IS) (S) 事务T2 加X锁 事务的并发控制 对任意元组加锁时，必须先对它所在的数据库和关系加意向锁。 多粒度封锁 提高了系统的并发度 减少了加锁和解锁的开销 在实际的数据库管理系统产品中得到广泛应用 事务的并发控制 事务的隔离级别 大多数商业DBMS允许应用程序选择封锁协议，例如要封锁哪些数据项，这些锁要保持多久。 隔离级别表示一个事务在与其他事务并发执行时所能容忍干扰的程度。 隔离级别越高，干扰越小，并发程度越低； 隔离级别越低，干扰越多，并发程度越高。 数据库系统允许由用户来选择一个可以保证应用程序正确执行并且能够使并发度最大的隔离性等级的执行选项。 封锁技术 事务的隔离级别 常用ANSI标准隔离级别来描述这些选项。 ANSI