数据库原理第章 V.ppt

严格两阶段锁 除要求满足两段锁协议规定外，还要求事务的排它锁必须在事务提交之后释放。 解决级联回滚问题 避免了脏读和丢失修改的问题。 强两阶段锁 除要求满足两段锁协议规定外，还要求事务的所有锁都必须在事务提交之后释放。 进一步解决数据项不能重复读的问题 两阶段锁总结 从两段锁协议到严格两段锁协议，再到强两段锁协议，事务持锁的时间不断增长。这不但保证事务的并发调度是冲突可串行化的，还不断增强了数据库的一致性保证。 但带来的另一方面的问题是并发度的降低，以及死锁出现可能性的增加。 目前，大多数的DBMS都采用严格两段锁协议或强两段锁协议。 锁的升级及更新锁 锁的升级有可能使得出现死锁的概率加大 更新锁只允许事务读取数据项而不能修改数据项 系统允许更新锁升级，而不允许共享锁升级 更新锁相容矩阵 Click to add Title 1 事务并发 1 Click to add Title 2 并发事务引起的问题 2 Click to add Title 2 可串行化 3 Click to add Title 1 基于锁的并发控制协议 4 Click to add Title 1 *活锁与死锁 5 Click to add Title 2 *多粒度封锁 3 活锁或饿死 解决活锁方法： 采用先来先服务的策略。 死锁 死锁的两种处理方式： 一种是进行死锁的预防，不让并发执行的事务出现死锁的状况； 一种是允许死锁的发生，在死锁出现后采取措施解决，为此系统中需增加死锁的检测及死锁的解除算法 顺序封锁法 将数据库对象按某种规定的顺序排列，要求事务实行封锁也必须按照这个顺序进行。 缺点： 不好确定数据库对象的封锁顺序。 维护封锁顺序是件困难的事情且成本很高 一次封锁法 要求事务在开始执行前先申请到所需的所有封锁，如果有一个封锁没有申请到，则事务中止。 缺点： 在事务开始前很难预先知道哪些数据项需要封锁； 一次将所有需要的封锁申请到，可能有些封锁只在事务运行的后期才需要，这就大大降低了系统的并发度。 时间戳法 根据事务启动时的时间戳设置事务的优先级，越早开始运行的事务优先级越高。 为预防死锁，在事务Ti申请的封锁与事务Tj已经拥有的封锁发生冲突时，锁管理器可使用如下两种不同的机制： Wait-die机制：若Ti优先级较高，则Ti可以等待；否则中止事务Ti。 Wound-wait机制：若Ti优先级较高，则中止Tj；否则Ti等待。 示例：假设事务T1、T2、T3的时间戳分别为5，10，20。 在Wait-die机制下： 若T1申请的封锁被T2拥有，则T1等待； T3申请的封锁被T2拥有，则T3中止运行做回滚操作。 在Wound-wait机制下： 若T1申请的封锁被T2拥有，则中止事务T2的运行； 若T3申请的封锁被T2拥有，则T3等待。 超时法： 规定申请锁事务等待的最长时间。若超过了规定时间，则系统判定出现死锁，此时该事务本身回滚并重启。 实现简单 可能出现误判 等待多长时间合适难以把握 等待图法： 当且仅当等待图中出现环路时，表示系统中存在死锁。 死锁的解除 选择一个或多个事务撤销，释放这个或这些事务拥有的封锁。 撤销事务的选择。 为解除死锁必须回滚处于死锁状态的部分事务。 撤销事务的选择原则是事务撤销所需的系统代价最小。 事务撤销的程度。 全部回滚选中事务，然后重新开始。 部分回滚选中事务，需要系统维护更多的事务运行状态信息。 Click to add Title 1 事务并发 1 Click to add Title 2 并发事务引起的问题 2 Click to add Title 2 可串行化 3 Click to add Title 1 基于锁的并发控制协议 4 Click to add Title 1 *活锁与死锁 5 Click to add Title 2 *多粒度封锁 3 封锁对象的大小称为封锁粒度（granularity) 封锁对象： 数据库的逻辑单位，如属性、元组、关系、索引、数据库等； 数据库的物理单位，如页、块等； 封锁粒度对并发度和资源消耗的影响： 若封锁粒度小，则系统并发度高，资源消耗多； 若封锁粒度大，则系统并发度低，资源消耗小； 不同事务可能需要不同的封锁粒度，系统允许同时为不同的事务提供不同的封锁粒度选择。 意向锁（intention lock） 如果对一个结点加意向锁，则意味着要对该结点的所有子孙结点显式加锁； 在一个结点显式加锁前，该结点的所有祖先结点都应加上意向锁。 意向锁类型 意向共享锁（IS锁）：如果一个结点加IS锁，那么将在该结点的子孙结点进行显式封锁，加S锁 意向排它