数据库原理与应用第八章并发控制要求和要点

1、数据库原理与应用第八章 并发控制要求和要点内容、提纲CH7.中讲到，为了保证事务的隔离性，需要对多个事务的并发操作进行控制 - 并发控制。本章介绍的并发控制技术属于事务处理技术。目的是保证事务的隔离性。事务是数据库恢复和并发控制的基本单位。8.1 并发控制概述8.2 封锁8.3 封锁协议8.4 活锁和死锁8.5 并发调度的可串行性8.6 两段锁协议8.7 封锁的粒度8.8 Oracle的并发控制教学要求掌握并发与串行的概念，并发事务的可串行化概念封锁的类型、封锁类型的相容矩阵封锁协议的要点和作用两段封锁协议，两段封锁法与可串行调度之间的关系了解理解并发操作带来的数据不一致问题活锁、死锁及其诊断

2、和解除数据库并发控制子系统的职责并发操作：串行执行数据库是一种共享资源，可供多个用户事务使用。多用户DBS: 允许多个用户事务同时使用的DBS, 多个用户事务可在同一时刻“并行”运行。 参见P264.多个用户事务在存取数据库的方式上, 可以:一个一个地串行执行, 串行存取DB数据；每个时刻只有一个事务在运行, 它独占系统的全部资源；如图示DB事务T1 t1t2事务T2 t2t3并发操作：并行执行多个事务并行地存取DB 参见P264.单处理机系统, 利用分时的方法, 多个事务轮流交叉运行 - 交叉并发方式。多处理机系统, 多个处理机并行运行, 实现多个事务真正的并行运行 - 同时并发方式。本章讨

3、论的“并发”是单处理机系统利用分时方法实现多个事务同时并行执行的交叉并发方式。单处理机中的并行操作是把处理机时间分成一些时间片，并行执行的事务依次轮流获得一个个时间片来运行。宏观上，在一段时间内有多个事务并行执行，但在某一时刻只有一个事务在运行。单处理机并发操作：图示 T1 T2 T3时间片 t11 t12 t13 t14 t15 t16 t1t2三个事务可以是代码一样的程序段，由不同的终端的用户装入运行，是不同的事务。由于处理机的高速性，使每个用户都感觉是在独占系统资源。数据库技术中事务的并发执行与操作系统中的多道程序设计概念类似。事务调度多个事务的执行顺序称为一个“调度”，表示多个事务的指

4、令在系统中执行的时间顺序。一组事务的调度必须保证包含了所有事务的操作指令；一个事务中指令的顺序必须保持不变。串行调度：多个事务的指令依次执行。在串行调度中，属于同一事务的指令紧挨在一起对于有n个事务的事务组，可以有n！个串行调度每一个串行调度都是有效的, 因为这些事务的执行互不干扰。事务并发调度并发调度：多个事务同时被处理(即交错执行)在并发调度中，来自不同事务的指令是交错的。并发调度的执行结果可能不正确。因为这些事务的执行可能互相干扰，需要进行控制。当并发调度执行的结果等于某个串行调度执行的结果时，则该并发调度是正确的。如何产生正确的并发调度，是由DBMS的并发控制子系统实现的。串行调度例两

5、个事务串行调度：read(A);write(A);T1T2read(B);rollback;read(A);Commit；read(A);write(A);T1T2read(B);rollback;read(A);Commit；并行(发)调度例两个事务并行调度：read(A);read(B);write(A);T1T2read(A)write(A);T3read(A)rollback;read(A);write(A);T1T2read(B);rollback;read(A);Commit；三个事务并行调度：8.1 并发控制概述DBMS并发调度子系统的职责协调并发事务的执行，保证数据库的一致性不

6、受破坏，同时避免用户得到不正确的数据。下面以几个例子说明在并发操作下，调度不当会带来数据的不一致性问题。有三类数据不一致性：参见P265.图8.1 丢失修改(丢失更新) 不可重复读(不一致分析) 读“脏”数据(依赖于未提交的更新)数据不一致性: 丢失修改丢失修改(丢失更新)一事务所做的更新操作因另一事务的操作而丢失。两种情况：(1) 一事务所做的更新结果被另一事务的更新结果“冲掉” 。 参见P265.图8.1(a)(2) 一事务所做的更新结果因另一事务的撤消而丢失。数据不一致性：丢失修改(续1)参见P265.图8.1(a)两个事务T1和T2读入同一数据并修改，T1(T2)提交的结果破坏了T2(

7、T1)提交的结果，导致T2(T1)的修改丢失T1T2 读A=16 AA-1 写回A=15读A=16AA-1写回A=15数据不一致性：丢失修改(续2) read(A); A := A 50; write(A); T1T2 *rollback* read(A); A := A10 write(A); 这个并发调度中，事务T2读入了未提交的A值，并由于事务T1撤消，使T2丢失了自己的修改。数据不一致性: 不可重复读不可重复读(不一致分析)：指事务从数据库中读取了处于不一致状态的数据，并因此进行了不一致的分析。三种情况： (1) 事务T1读取某一数据后,事务T2对其做了修改, 当T1再次读取该数据时,

8、 得到与前一次不同的值。参见P265.图8.1(b)读B=100 BB*2写回B=200 读A=50 读B=100 求和=150 读A=50 读B=200 求和=250 (验算不对) T2T1数据不一致性: 不可重复读(续)参见P266.(2) 事务T1按一定条件从数据库中读取某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录消失了。(3) 事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。后两种不可重复读也称为幻影现象。数据不一致性: 读脏数据读“脏”数据（依赖于未提交更新）：指一事

9、务取用了别的事务未提交随后又被撤消的数据。 参见P266.在数据库技术中, 把未提交随后又被撤消的数据称为“脏”数据。数据不一致性: 读脏数据例事务T1修改某一数据并将其写回, 但未提交, 事务T2读取同一数据后, T1由于某种原因被撤消，这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就是“脏”数据。读C=200 读C=100 CC*2 写回C ROLLBACK C恢复为100T2T1参见P265.图8.1(c)并发控制的技术：封锁产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作，使一个用户事务的执

10、行不受其他事务的干扰，从而避免数据的不一致性，保证事务的隔离性，保证数据库的一致性。并发控制有两种技术：封锁(Locking)技术和时标(Times-tamping)技术，大多数DBMS采用封锁技术。8.2 封锁(Locking)封锁是实现并发控制的一个非常重要的技术。封锁: 是指事务向系统发出对某数据对象加锁的请求，以取得对该对象一定的控制权。 向系统发出请求加锁R系统不允许T等待如，事务T： 要操作数据对象R 确切的控制由封锁的类型决定。允许 T可读写 R 其他事务不能更新R T释放R上的锁，其他事务可请求加锁R封锁的类型: X锁基本的封锁类型 参见P266.267.排它锁(Exclusi

11、ve Locks，简称X锁，又称写锁 )共享锁(Share Locks，简称S锁，又称读锁)X封锁：若一个事务T对数据对象A加上X锁，则只允许T读取和修改A，在T释放A上的X锁之前不允许其他事务再对该数据对象A加任何类型的锁，即其他事务不能读写数据对象A。欲修改(写)数据A，必须先对A加X锁X锁是写锁，写操作是排它的，排它的写封锁的类型: S锁 参见P266.267.S封锁：若一个事务T对数据对象A加上S锁，则事务T可以读取A但不能修改A，允许其他事务再对该数据对象A加S锁，但在T释放A上的S锁之前不允许其他事务对A加X锁。欲读取数据A，先对A加S锁 S锁是读锁，读操作是共享的，共享的读排它锁

12、和共享锁的相容矩阵参见P267.图8.2 封锁类型的相容矩阵 X S - N N Y N Y Y Y Y Y X S -T1T2 X 表示X封锁 S 表示S封锁 - 表示不加任何锁 Y 表示相容的请求 N 表示不相容的请求若两个封锁是不相容的, 则后提出封锁的事务要等待申请对数据R加X锁 - Xlock R申请对数据R加S锁 - Slock R8.3 封锁协议对锁的操作有：加锁、升级和释放(解锁)。X锁和S锁具有不同性质，但锁本身并未规定事务存取数据库时必须进行锁操作。封锁协议规定了事务何时必须进行锁操作和进行怎样的锁操作，即规定了事务存取数据库时必须进行的锁操作。DBMS不但要有专门的子系统

13、执行锁操作，而且要有监督事务遵守封锁协议的功能。封锁机制是通过封锁类型、封锁协议和有关的子系统来实现的。封锁协议封锁协议：在运用X锁和S锁对数据对象加锁时，还需要约定一些规则，要求并发执行的事务共同遵守。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。保证事务一致性的封锁协议一级封锁协议 参见P267.268.二级封锁协议 参见P268.三级封锁协议 参见P268.保证事务一致性的封锁协议：一级一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直至事务结束才释放。事务结束包括提交和回滚。一级封锁协议可以防止丢失修改，并保证事务是可恢复的。T1T2 Xlock A 获得 读A=16AA

14、-1 写回A=15 Commit Unlock AXlock A等待等待等待等待获得Xlock A读A=15AA-1写回A=14CommitUnlock A参见P269.图8.3 (a)没有丢失修改一级封锁协议：例1在一级封锁协议中，如果仅仅是读数据，不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读“脏”数据。 Xlock B 获得 读B=100 BB*2 写回B=200 Commit Unlock B读A=50 读B=100 求和=150读A=50 读B=200 求和=250 (验算不对) T2T1例: 不可重复读一级封锁协议：例2在一级封锁协议中，如果仅仅是读数据，不对其进行修

15、改，是不需要加锁的，所以它不能保证可重复读和不读“脏”数据。 读A=15 Xlock A 获得 读A=16 AA-1 写回A=15 RollbackUnlock AT2T1例: 读“脏”数据保证事务一致性的封锁协议：二级二级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。二级封锁协议可以防止丢失修改，还可进一步防止读“脏”数据。例：参见P269.图8.3(C ) 不读“脏”数据Xclock C 获得 读C=100 CC*2 ROLLBACK C恢复为100 Unlock C Slock C 等待 等待 等待 等待 获得 Slock C 读C=100 Com

16、mit Unlock CT2T1二级封锁协议：例在二级封锁协议中, 由于读完数据后即释放S锁,所以它不能保证可重复读。Sclock A 获得 读A=50 Unlock A Sclock B 获得 读B=200 Unlock B 求和=250 (验算不对) T2T1 (续)Sclock A 获得 读A=50 Unlock A Sclock B 获得 读B=100 Unlock B 求和=150 Xlock B 等待 等待 获得Xlock B 读B=100 BB*2 写回B=200 Commit Unlock BT2T1保证事务一致性的封锁协议：三级三级封锁协议：一级封锁协议加上事务T在读取数据R

17、之前必须先对其加S锁，直到事务结束才释放锁。三级封锁协议除防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。例：参见P269.图8.3 (b)可重复读图8.3(C )不读“脏”数据T1T2 Slock A 读A=50 Slock B 读B=100 求和=150 读A=50 读B=100 求和=150 Commit Unlock A Unlock B Xlock B 等待 等待 等待 等待 等待 等待 等待 等待 获得Xlock B 读B=100 BB*2 写回B=200 Commit Unlock B 保证事务一致性的封锁协议三个级别封锁协议的主要区别：什么操作需要申请封锁、申请什么

18、封锁；何时释放锁(持锁时间)、及数据一致性的保证。P269., 不同级别的封锁协议与数据一致性保证 X 锁 S锁 一致性保证操作结束释放事务结束释放操作结束释放事务结束释放不丢失修改不读“脏”数据可重复读一级封锁协议 二级封锁协议 三级封锁协议 8.4 活锁和死锁恰当地运用封锁技术，可以有效地避免数据不一致，但有可能引起其他问题：活锁和死锁。活锁出现某个事务永远处于等待状态，得不到封锁的机会，这种现象称为活锁(Live Lock)。例如，P270.图8.4(a)的活锁现象，事务T2永远等待。活锁的避免避免活锁的简单方法是采用“先来先服务”排队的策略。 参见P270.当多个事务请求封锁同一数据对

19、象时，封锁子系统按请求封锁的先后次序对事务排队，数据对象上的锁一旦释放就批准申请队列的第1个事务获得锁。如果事务有优先级，那么很可能优先级低的事务即使排队也很难轮上封锁的机会。此时可采用锁“升级”方法来解决，也就是当一个事务等待若干时间（比如5分钟）还轮不上封锁时，可以提高其优先级，这样总能轮上获得封锁。死锁(参见P270.271.)出现两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执行，这种现象称为系统进入了“死锁”(Dead Lock)状态。例如，参见P270.图8.4(b)，事务T1和T2各自封锁了一些数

20、据对象，又请求封锁对方已加锁的数据对象，造成互相等待，永远不能结束的局面。Xlock R1.Xlock R2等待等待等待.Xlock R2.Xlock R1等待等待.T1T2死锁的解除 数据库中解除死锁的两类方法：1. 死锁的预防：采取一定措施预防死锁的发生。2. 诊断解锁：允许死锁发生，采取一定手段定期诊断系统中有无死锁，有则解除之。死锁的预防：一次封锁法 防止死锁的发生，破坏产生死锁的条件, 两法：(1) 一次封锁法 参见P271.要求所有事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。例如，P270.图8.4(b)中, 如果事务T1和T2将数据对象R1和R2一次加锁, 这样就

21、不会发生死锁。如事务T1 ： “锁R1, R2；读写R2, R2；解锁R1, R2；”一次封锁法可以有效地防止死锁，但会扩大封锁范围，降低系统的并发度。死锁的预防：顺序封锁法(2) 顺序封锁法 参见P271.预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。如P270.图8.4(b)中，事务T1和T2都按如下顺序加锁： “锁R1, 读写R1, 锁 R2, 读写R2解锁R1, R2 ”顺序封锁法可以有效地防止死锁, 但维护成本高，实现困难。因为:死锁的预防：顺序封锁法 DBS中封锁的数据对象极多，并且随数据的插入、删除等操作而不断地变化，要维护这样的封锁序列非常困难； 事务的封锁请求

22、可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象。例如：规定数据对象的封锁顺序为A、B、C、D、E。事务T3起初要求封锁数据对象B、C、E，但当它封锁了B、C后，才发现还需要封锁A，这样就破坏了封锁顺序。死锁的诊断与解除DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法：不采取任何措施预防死锁的发生，而采用某种方法诊断系统中是否有死锁，发现有死锁则设法解除。死锁的诊断方法(1) 超时法 参见P271.272.规定一个时限，如果一个事务等待时间超过了这个时限就认为发生了死锁。实现简单，但有可能误判死锁，事务有可能因为其他原因等待超时；时限设置太长，则又不能及时发现死锁

23、。死锁的诊断：等待图法(2) 等待图法(依赖图法) 参见P272.结点 - 事务有向边 - 箭尾事务等待箭头事务解锁例如P270.图8.4(b)中的两个事务间的依赖关系，如图所示。DBMS周期地测试系统中是否出现了死锁。用事务等待图的形式可以测试系统中是否存在死锁。如果在事务等待图中，沿着箭头方向存在一个循环，那么表示已出现死锁现象。T1T2数据 R2数据 R1死锁的诊断：等待图法T1T2T3T4无环等待图,表示系统未进入死锁状态T1T2T3T4有环等待图,表示系统进入死锁状态死锁的解除方法DBMS中有一个死锁测试程序, 每隔一段时间检查并发的事务之间是否发生死锁。如果发生死锁，那么按某种标准

24、(例如处理代价最小的)从卷入死锁的事务中选择某个事务作为牺牲品, 将其撤消，回滚这个事务, 恢复该事务所做的数据更新，并释放此事务持有的所有封锁和所占有的资源, 使其他事务有可能继续运行下去，这就有可能消除死锁现象。理论上，系统进入死锁状态时可能会有许多事务在相互等待，但是，System R的实验表明，实际上绝大部分死锁状态只涉及到两个事务。8.5 并发调度的可串行性 一、什么样的并发操作调度是正确的 二、如何保证并发操作的调度是正确的并发调度的正确性如果有n个事务串行调度，可以有n！种不同的串行调度。事务的任一串行调度的结果尽管可能不同，但都是有效的(正确的)，因为它不会将DB置于不一致状态

25、。如果有n个事务并发调度，可能的并发调度数目远远大于n！。但其中有的并发调度是正确的，有的是不正确的。如何产生正确的并发调度，是由DBMS的并发控制子系统实现的。如何判断一个并发调度是正确的，这个问题可以用下面的“并发调度的可串行化”概念来解决。并发调度的可串行性并发调度的可串行化定义 参见P272.如果一个并发调度与某一串行调度具有相同的执行结果，则称这个并发调度是“可串行化的调度”, 否则是不可串行化的调度。可串行性(Serializability)是并发调度正确性的准则： 一个并发调度是正确的 该并发调度是可串行化的可串行化例事务T1：读B；A=B+1；写回A； 参见P272. 事务T2

26、：读A；B=A+1；写回B； 假设A，B的初值均为2。参见P273.图8.5，给出了对这两个事务的四种不同的调度策略(增加了封锁机制)： (a)图 串行调度T1T2, 执行结果为A=3，B=4； (b)图串行调度T2T1, 执行结果为A=4，B=3； (c)图并行调度, 执行结果为A=3，B=3; 不可串行化的； (d)图并行调度, 执行结果为A=3，B=4; 是可串行化的。8.6 两段锁协议目前DBMS普遍采用封锁方法实现并发操作调度的可串行性，从而保证并发调度的正确性。因此仍然采用封锁协议要求事务遵守。 参见P274.保证并发调度可串性化的封锁协议：两段锁协议。两段锁协议(Two-Phas

27、e Locking, 简称2PL)指所有事务必须分两个阶段对数据项加锁和解锁。两段锁协议两段锁协议规定所有事务遵守: 参见P274.(1) 在对任何数据进行读写操作前,首先要申请并获得对该数据的封锁;(2) 在释放一个封锁之后,事务不再申请和获得任何其他封锁。“两段锁”的含义是指事务分为两个阶段： 获得封锁阶段(扩张阶段)，事务可申请获得任何数据项上的任何类型的锁，但是不能释放任何锁。释放封锁阶段(收缩阶段)，事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。两段锁协议：简例 参见P274.例如，事务T1遵守两段锁协议，其封锁序列是：Slock A Slock B Xlock C

28、加锁阶段Unlock B Unlock A Unlock C； 解锁阶段又如，事务T2不遵守两段锁协议，其封锁序列是：Slock A Unlock A Slock B Xlock C Unlock C Unlock B ； 加解锁操作交错，不能分为两个阶段两段锁协议: 说明1(1) 可以证明，若并发执行的所有事务都遵守“两段锁”协议，则对这些事务的任何并发调度都是可串行化的。 参见P274.但是，事务遵守“两段锁”协议是可串行化调度的充分条件，而不是必要条件。即 若并发事务都遵守“两段锁”协议 则对这些事务的任何并发调度都是可串行化。 反之不一定成立。即若多个事务的并发调度是可串行化的, 而这

29、些并发事务不一定都遵守“两段锁”协议 。两段锁协议: 例参见P272.的例，两个事务串行执行结果是 A=3，B=4 或 A=4，B=3P275.图8.6(a)和(b)的并发调度都是可串行化的。(a)图 并发调度执行的结果是A=3, B=4; 且(a)图并发调度中的两个事务都遵守两段锁协议。(b)图并发调度执行的结果是A=3, B=4; 但(b)图并发调度中的两个事务都不遵守两段锁协议。两段锁协议: 说明2(参见P274.)(2) “两段锁”协议和防止死锁的一次封锁法的异同一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁, 否则就不能继续执行。一次封锁法遵守“两段锁”协议。一次封锁法的要

30、求比“两段锁”协议更强。例如下面的两个事务： T1: 一次加锁，也遵守两段锁协议 锁A，B，C；读写A，B，C；解锁A，B，C； T2: 遵守两段锁协议, 而不是一次加锁 锁A，读写A，锁B，读写B；解锁A，B；两段锁协议: 说明3(参见P274.) (3) 遵守“两段锁”协议的事务可能发生死锁 因为“两段锁”协议不要求事务必须一次将所有要使用的数据全部加锁，可以分多次对要使用的数据加锁，边锁边读写数据。例如P275.所示T1Slock B读B=2Xlock A等待等待T2Slock A读A=2Xlock B等待两段锁协议: 说明4(4) 两段锁协议与三级封锁协议的比较： 两类不同目的的协议两

31、段锁协议：保证并发调度的正确性；三级封锁协议：在不同程度上保证数据一致性。 遵守保证数据一致性的第三级封锁协议必然遵守两段锁协议。8.7 封锁的粒度 参见P276.X锁和S锁都是加在某一个数据对象上的。 封锁的数据对象: 可以是逻辑单元或物理单元 例：在关系数据库中，封锁的数据对象：逻辑单元: 属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等物理单元：页（数据页或索引页）、物理记录、物理块等 封锁对象可以很大也可以很小。 例： 对整个数据库加锁 - 大 对某个属性值加锁 - 小封锁的粒度 参见P276.封锁的粒度(Granularity)：指封锁的数据对象的大小。封锁的粒度与系统

32、的并发度和并发控制的开销密切相关封锁的粒度越大，DBS所能够封锁的数据单元就越少，并发度就越小，系统开销也越小；封锁的粒度越小，DBS所能够封锁的数据单元就越多，并发度就越大，系统开销也越大。封锁粒度与并发度、系统开销 例， 参见P276. 若封锁粒度是数据页，事务T1需要修改元组L1，则必须对包含L1的整个数据页A加锁。如果T1对A加锁后，事务T2要修改A中的元组L2，则T2被迫等待，直到T1释放数据页A。 若封锁粒度是元组，则事务T1和T2可以同时对元组L1和L2加锁，不需要互相等待，提高了系统的并发度。数据页A元组 L1元组 L2元组 L3封锁粒度与并发度、系统开销(续) 如果事务T需要

33、读取整个表，封锁粒度应该是表。如果封锁粒度是元组，则T必须对表中的每个元组加锁，显然开销极大。 参见P276.表元组 1元组 2元组 3选择封锁粒度的原则 参见P276.选择封锁粒度的原则：应该同时考虑封锁开销和并发度两个因素，适当选择封锁粒度以求得最优的效果。 以关系数据库为例，一般，需要处理大量元组的事务可以以关系为封锁粒度；需要处理多个关系的大量元组的事务可以以数据库为封锁粒度；而对于一个处理少量元组的事务以元组为封锁粒度就比较合适。8.7.1 多粒度封锁 参见P276.如果在一个系统中同时支持多种封锁粒度供不同的事务选用是比较理想的。支持多种封锁粒度的方法称为多粒度封锁(Multipl

34、e Granularity Locking)在一个系统中同时支持多种封锁粒度供不同的事务选择。多粒度树（参见P276.）1.多粒度树：以树形结构来表示多级封锁粒度。事务存取的数据对象之间往往自然形成一种层次(树)结构。多粒度树的根结点是整个数据库，表示最大的封锁粒度；叶结点表示最小的封锁粒度。例，P276.给出了一个关系数据库的三级封锁粒度树根结点为DBDB的子结点为关系关系的子结点为元组数据库关系关系元组 元组元组 元组多粒度封锁协议2.多粒度封锁的封锁协议 参见P277. 也称层次结构的加锁方法：(1) 允许多粒度树中的每个结点被独立加锁。(2) 对一个结点加锁意味着对这个结点的所有后裔结

35、点也被加以同样类型的锁。例如，左图的多粒度树按照多粒度封锁协议，在多粒度封锁中，一个数据对象可能以两种方式加锁：显式封锁隐式封锁数据库关系关系元组 元组元组 元组多粒度封锁显式封锁：是应事务的要求(有lock语句)直接加到数据对象上的封锁。 参见P277.隐式封锁：是该数据对象没有被独立加锁(无lock语句)，是由于其上级结点的加锁而使该数据对象加上了锁。在多粒度封锁方法中，显式封锁和隐式封锁的效果是一样的。系统检查封锁冲突时，不仅要检查显式封锁，还要检查隐式封锁。多粒度封锁: 锁的检查该数据对象 参见P277.有无显式封锁与之冲突 所有上级结点检查本事务的显式封锁是否与该数据对象上的隐式封锁

36、冲突：(由上级结点封锁造成的)所有下级结点看下级结点上的显式封锁是否与本事务的隐式封锁(将加到下级结点的封锁)冲突。多粒度封锁: 锁的检查例DBR1Rn元组 元组元组 元组例如，事务T要对关系R1加X锁，系统必须检查本结点R1，其上级结点DB，以及R1中的下级每个元组结点，如果其中某一个数据对象上已经加了不相容的锁，则T必须等待。下级：显式，隐式(本级导致)本级：显式，隐式(上级导致)上级8.7.2 意向锁 参见P277.引进意向锁(Intention Lock)的目的：提高系统检查多粒度树中封锁冲突的效率。意向锁的含义：如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁； - 警告:

37、下层结点正在被加锁对任意一个结点加锁时，必须先对它的上层结点加意向锁。 - 下层结点欲加锁，先放一个警告在上层结点意向锁例 参见P277.例：对任一元组 r 加锁时，必须先对它所在的关系R加意向锁。 如图：事务T要对关系R加X锁, 系统只要检查根结点DB和关系R是否已加了不相容的锁，而不再需要搜索和检查R中的每一个元组r是否加了X锁。因为如果元组r上加了X锁的话，其上层的关系R已加上了意向锁(即放了警告)，只需检查关系R和DB上的锁即可。DBR1Rn元组 元组元组 元组三种意向锁有三种常用的意向锁： 参见P277.1. 意向共享锁( IS锁，Intent Share Lock)2. 意向排它锁

38、( IX锁，Intent Exclusive Lock)3. 共享意向排它锁( SIX锁， Share Intent Exclusive Lock)意向共享锁1. 意向共享锁( IS锁, 警告读锁) 参见P277.如果对一个数据对象加IS锁, 表示它的后裔结点拟(意向)加S锁。例如，要对某个元组加S锁，则要首先对关系和DB加IS锁。即，下层拟加S锁，则先在上层结点加IS锁。DBR1Rn元组 元组元组 元组意向排它锁2. 意向排它锁( IX锁，警告写锁) 参见P277.如果对一个数据对象加IX锁, 表示它的后裔结点拟(意向)加X锁。例如，要对某个元组加X锁，则要首先对关系和DB加IX锁。即，下层

39、拟加X锁，则先在上层结点加IX锁。DBR1Rn元组 元组元组 元组共享意向排它锁3.共享意向排它锁( SIX锁,警告读写锁)如果对一个数据对象加SIX锁, 表示对它加S锁, 再加IX锁, 即SIX=S+IX。 参见P277.例如，事务对某个表加SIX锁，则表示该事务要读取整个表(所以要对该表加S锁), 同时会更新个别元组(元组拟加X锁, 所以要对该表加IX锁)。即，本层欲加S锁, 下层拟加X锁，则在本层加SIX锁。DBR1Rn元组 元组元组 元组具有意向锁的多粒度封锁方法具有意向锁的多粒度封锁方法 参见P278.申请封锁时应该按照自上而下的次序进行释放封锁时则应该按自下而上的次序进行在具有意向

40、锁的多粒度封锁方法中，任意事务T要对一个数据对象加锁，必须先对它的上级结点加意向锁。具有意向锁的多粒度封锁方法提高了系统的并发度，减少了加锁和解锁的开销。五种数据锁的相容矩阵和强度五种数据锁的相容矩阵参见P278.图8.9(a)锁的强度: 指它对其他锁的排斥程度。五种锁的强度有偏序关系。参见P278.图8.9(b)XSIXS、IXIS不加锁一个事务在申请锁时以强锁代替弱锁是安全的，反之则不然。XSIXIXSIS-SQL Server 的并发控制 参见实验教材的综合实验1“并发控制” P88.P90.SQL Server采用封锁技术保证并发操作的可串行性。SQL Server有三种封锁机制：共享

41、封锁：读锁更新封锁：修改锁，不包括插入和删除独占封锁：排他锁SQL Server的封锁命令（封锁关键词）TABLOCK：对表施加共享锁，读完立即释放锁，避免读“脏”数据，但可能引起不可重复读问题HOLDLOCK：与TABLOCK 一起使用，事务完成才释放共享锁，可以保证数据的可重复读SQL Server 的并发控制（续）NOLOCK：不施加任何封锁，仅用于select语句TABLOCKX：对表施加排他锁UPDLOCK：对表中指定的元组施加更新锁SQL Server的隔离级别未提交读（READ UNCOMMITED），最低级，保证不读物理损坏的数据提交读（READ COMMITED），默认级别，

42、保证不读“脏”数据可重复读（REPEATABLE READ），保证读一致性可串行化（SERIALIZABLE），最高级别，保证事务均是可串行的SQL Server的封锁类型6种锁模式：共享、排它、更新、结构、意向、块更新9种锁类型：S 共享锁、 X 排它锁、U 更新锁、IX 排它意向锁、SIX 排它共享意向锁、IS 共享意向锁、Sch-M 结构修改锁、Sch-S 结构稳定锁、BU 块更新锁系统表 syslockinfo 包含了全部授权的、转换的、等待的锁请求信息。SQL Server的封锁粒度封锁粒度(加锁资源): DB 数据库Key 具有索引的行数据TAB 整个表，包括数据和索引PAG 页面，8K字节TEXT 区域(簇)，一组连续的8个数据页或索引页RID 表中单行数据用系统存储过程 sp-lock可以查看当前锁的情况。SQL Server的空间管理及锁的级别(1) 行级锁: 行级锁是指事务操作过程中，锁定一行或若干行数据。 (2) 页级锁: 一个页有8K