本章目录
第11章 并发控制
数据库是一个共享资源,可以供多个用户使用,这样的数据库称为多用户数据库系统。
在单处理机系统中,事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行,如图11.1(b)所示。这种并行执行方式称为交叉并发方式。
在多处理机系统中,每个处理机可以运行一个事务,多个处理机同时运行多个事务,实现多个事务的真正的并发运行,这种方式称为同时并发方式。
11.1 并发控制概述
为了保证事务的隔离性和一致性,数据库管理系统需要对并发操作进行正确调度。并发操作带来的数据不一致性包括:丢失修改,不可重复读和读“脏”数据。
- 丢失修改(lost update)
两个事务T1和T2读入同一数据并修改,T2 提交的结果破坏了T1提交的结果,导致T1的修改被丢失。 - 不可重复读(non-repeatable read)
不可重复读是指事务T1读取数据后,事务T2执行更新操作,使T1无法再现前一次读取结果。具体地讲,不可重复读包括三种情况:
(1)事务T1读取某一数据后,事务T2对其进行了修改,当事务T1再次读该数据时,得到与前一次不同的值。
(2)事务T1按一定条件从数据库中读取了某些数据记录后,事务T2删除了其中部分记录,当T1再次按相同条件读取数据时,发现某些记录神秘地消失了。
(3)事务T1按一定条件从数据库中读取某些数据记录后,事务T2插入了一些记录,当T1再次按相同条件读取数据时,发现多了一些记录。 - 读“脏”数据(dirty read)
读“脏”数据是指事务T1修改某数据并将其写回磁盘, 事务T2读取同一数据后,T1由于某种原因被撤销,这时被T1修改过的数据恢复原值,T2读到的数据就与数据库中的数据不一致,则T2读到的数据就为“脏”数据,即不正确的数据。
产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制机制就是要用正确的方式调度并发操作,使一个用户事务的执行不受其他事务的干扰,从而避免造成数据的不一致性。
并发控制的主要技术有封锁( locking)、时间戳( timestamp)、乐观控制法( optimistic scheduler)和多版本并发控制( multi-version concurrency control, MVCC)等。
11.2 封锁
- 封锁就是事务T在对某个数据对象操作之前,先向系统发出请求,对其加锁。加锁后事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,其他事务不能更新此数据对象。
- 确切的控制由封锁的类型决定。基本的封锁类型有两种:排他锁( exclusive locks,简称X锁)和共享锁(share locks,简称S锁)。
排他锁又称为写锁。 若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他任何事务都不能再对A加任何类型的锁,直到T释放A上的锁为止。这就保证了其他事务在T释放A.上的锁之前不能再读取和修改A。
共享锁又称为读锁。若事务T对数据对象A加上S锁,则事务T可以读A但不能修改A,其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁为止。这就 - 排它锁和共享锁的控制方式可以用图11.3所示的相容矩阵来表示:
11.3 封锁协议
- 一级封锁协议
一级封锁协议是指,事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。事务结束包括正常结束(COMMIT)和非正常结束(ROLLBACK)。
一级封锁协议可防止丢失修改,并保证事务T是可恢复的。 - 二级封锁协议
二级封锁协议是指,在一.级封锁协议基础上增加事务T在读取数据R之前必须先对其加S锁,读完后即可释放S锁。
二级封锁协议除防止了丢失修改,还可进一步防止读“脏”数据。 - 三级封锁协议
三级封锁协议是指,在一级封锁协议的基础上增加事务T在读取数据R之前必须先对其加S锁,直到事务结束才释放。
三级封锁协议除了防止丢失修改和读“脏”数据外,还进一步防止了不可重复读。
上述三级协议的主要区别在于什么操作需要申请封锁,以及何时释放锁(即持锁时间)。三级封锁协议可以总结为表11.1。
11.4 活锁和死锁
11.4.1 活锁
如果事务T1封锁了数据R,事务T2又请求封锁R,于是T2等待; T3 也请求封锁R,当T1释放了R上的封锁之后系统首先批准了T3的请求,T2仍然等待;同理,然后又批准了T4是请求……。T2就有可能永远处于等待,这就是活锁。
避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时,封锁子系统按请求封锁的先后次序对事务排队,数据对象上的锁一旦释放就批准申请队列中第一个事务获得锁。
11.4.2 死锁
如果事务T1封锁了数据R1,T2封锁了数据R2,然后T1又请求封锁R2,因T2已封锁了R2,于是T1等待T2释放R2上的锁;接着T2又申请封锁RI,因T1已封锁了R1,T2也只能等待T1 释放R1上的锁。这样就出现了T1在等待T2,而T2又在等待T1的局面,T1和T2两个事务永远不能结束,形成死锁。
死锁问题的解决主要有两类方法:一类方法是采取一定措施来预防死锁的发生;另一类方法是允许发生死锁,采用一定手段定期诊断系统中有无死锁,若有则解除之。
- 死锁的预防
数据库中,产生死锁的原因是两个或多个事务都已封锁了一些数据对象,然后又都请求对已被其他事务封锁的数据对象加锁,从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有以下两种方法。
(1)一次封锁法
一次封锁法要求每个事物必须一次将所有要使用的数据全部加锁,否则就不能继续执行。
一次封锁法虽然可以有效地防止死锁的发生,但也存在问题,第一,一次就将以后要用到的全部数据加锁,势必扩大了封锁的范围,从而降低了系统的并发度;第二,数据库中数据是不断变化的,原来不要求封锁的数据在执行过程中可能会变成封锁对象,所以很难事先精确地确定每个事务所要封锁的数据对象,为此只能扩大封锁范围,将事务在执行过程中可能要封锁的数据对象全部加锁,这就进一步降低了并发度。
(2)顺序封锁法
顺序封锁法是预先对数据对象规定一个封锁顺序,所有事务都按这个顺序实施封锁。
顺序封锁法可以有效地防止死锁,但也同样存在问题,第一,数据库系统中封锁的数据对象极多,并且随数据的插入、删除等操作而不断地变化,要维护这样的资源的封锁顺序非常困难,成本很高;第二,事务的封锁请求可以随着事务的执行而动态地决定,很难事先确定每个市仪西封锁哪些对象,因此也就很难按规定的顺序去施加封锁。
- 死锁的诊断与接触
数据库系统中诊断死锁的方法与操作系统类似,一般使用超时法或事务等待图法。
(1)超时法
如果一个事务的等待时间超过了规定的时限,就认为发生了死锁。
超时法实现简单,但也有问题,一是有可能误判死锁,如事务因为其他原因而使等待时间超过时限,系统会误认为发生了死锁;二是时限若设置得太长,死锁发生后不能及时发现。
(2)等待图法
事务等待图是一个有向图G=(T, U), T为结点的集合,每个结点表示正运行的事务: U为边的集合,每条边表示事务等待的情况。若T1等待T2,则在T1、T2之间画一条有向边,从T1指向T2。如图11.6所示。
事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地(比如每隔数秒)生成事务等待图,并进行检测。如果发现图中存在回路,则表示系统中出现了死锁。
数据库管理系统的并发控制子系统一旦 检测到系统中存在死锁,就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务,将其撤销,释放此事务持有的所有的锁,使其他事务得以继续运行下去。当然,对撤销的事务所执行的数据修改操作必须加以恢复。
11.5 并发调度的可串行性
数据库管理系统对并发事务不同的调度可能会产生不同的结果,执行结果等价于串行调度的调度也是正确的,这样的调度叫做可串行化调度。
11.5.1 可串行化调度
定义:多个事务的并发执行是正确的,当且仅当其结果与按某一次序串行地执行这些事务时的结果相同,称这种调度策略为可串行化(serializable)调度。
可串行性( serializability)是并发事务正确调度的准则。按这个准则规定,一 个给定的并发调度,当且仅当它是可串行化的,才认为是正确调度。
11.5.2 冲突可串行化调度
冲突操作是指不同的事务对同一个数据的读写操作和写写操作,其他操作是不可能产生冲突的。
不同事务的冲突操作和同一事务的两个操作是不能交换(swap)的。对于Ri(x)与Wi(x),若改变二者的次序,则事务Ti看到的数据库状态就发生了改变,自然会影响到事务Ti后面的行为。对于Wi(x)与Wj(x),改变二者的次序也会影响数据库的状态,x的值由等于Tj的结果变成了等于Ti的结果。
一个调度Sc在保证冲突操作的次序不变的情况下,通过交换两个事务不冲突操作的次序得到另一个调度Sc’,如果Sc是串行的,称调度Sc为冲突可串行化的调度。若一个调度是冲突可串行化,则一定是可串行化的调度。因此可以用这种方法来判断一个调度是否是冲突可串行化的。
11.6 两段锁协议
- 为了保证并发调度的正确性,数据库管理系统的并发控制机制必须提供一定的手段来保证调度是可串行化的。目前数据库管理系统普遍采用两段锁(TwoPhase Locking, 简称2PL)协议的方法实现并发调度的可串行化,从而保证调度的正确性。
- 两段锁协议是指:所有的事务必须分两个阶段对数据项加锁和解锁:
(1)在对任何数据进行读、写操作之前,首先要申请并获得对该数据的封锁:
(2)在释放一个封锁之后,事务不再申请和获得任何其他封锁。
所谓“两段"锁的含义是,事务分为两个阶段,第一阶段是获得封锁,也称为扩展阶段,在这个阶段,事务可以申请获得任何数据项上的任何类型的锁,但是不能释放任何锁;第二阶段是释放封锁,也称为收缩阶段,在这个阶段,事务可以释放任何数据项上的任何类型的锁,但是不能再申请任何锁。
可以证明,若并发执行的所有事务均遵守两段锁协议,则对这些事务的任何并发调度策略都是可串行化的。
需要说明的是,事务遵守两段锁协议是可串行化调度的充分条件,而不是必要条件。
- 另外,要注意两段锁协议和防止死锁的一次封锁法的异同之处。
一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行。因此,一次封锁法遵守两段锁协议;
但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁,因此遵守两段锁协议的事务可能发生死锁,
11.7 封锁的粒度
封锁对象的大小称为封锁粒度。封锁对象可以是逻辑单元(属性值、属性值的集合、元组、关系、索引项等),也可以是物理单元(页、物理记录等)。
封锁粒度与系统的并发控制的开销是密切相关的。粒度越大,数据单元越小,反之,粒度越小,数据单元越大。因此,如果在一个系统中支持多种封锁粒度供不同的事务选择是比较理想的。这种封锁方法称为多粒度封锁。
选择封锁粒度时应考虑封锁开销和并发度两个因素。
11.7.1 多粒度封锁
- 多粒度封锁的根节点是整个数据库,表示最大的数据粒度。叶节点表示最小的数据粒度。
- 图11.10给出了一个三级粒度树。根结点为数据库,数据库的子结点为关系,关系的子结点为元组。
也可以定义4级粒度树,例如数据库、数据分区、数据文件、数据记录。 - 多粒度封锁协议允许多粒度树中的每个结点被独立地加锁。对一个结点加锁意味着这个结点的所有后裔结点也被加以同样类型的锁。因此,在多粒度封锁中一个数据对象可能有两种方式,显示封锁和隐式封锁。
(1)显示封锁:应事务的要求直接加到数据对象上的锁:
(2)隐式封锁:该数据对象没有被单独加锁,是由于其上级结点加锁二是该数据对象加上了锁。
多粒度封锁法方法中,显示封锁和隐式封锁的效果是一样的。因此,系统要检查数据对象及其上级结点、下级结点是否加锁
11.7.2 意向锁
有了意向锁,数据库管理系统就无须逐个检查下一级结点的显示封锁。
意向锁:如果对一个结点加意向锁,则说明该节点的下层结点正在被加锁,对任意结点加锁时,必须先对它的上层结点加意向锁。
- IS锁
如果对一个数据对象加IS锁,表示它的后裔结点拟(意向)加S锁。 - IX锁
如果对一个数据对象加IX锁,表示它的后裔结点拟(意向)加X锁。 - SIX锁
如果对一个数据对象加SIX锁,表示对它加S锁,再加IX锁,即SIX=S+IX.
图11.11(a)给出了这些锁的相容矩阵,从中可以发现这5种锁的强度有如图11.1 1(b)所示的偏序关系。所谓锁的强度是指它对其他锁的排斥程度。一个事务在申请封锁时以强锁代替弱锁是安全的,反之则不然。
在具有意向锁的多粒度封锁方法中,任意事务T要对一个数据对象加锁,必须先对它的上层结点加意向锁。申请封锁时应该按自上而下的次序进行,释放封锁时则应该按自下而上的次序进行。
11.8 其他并发控制机制
并发控制的方法除了封锁技术外还有时间戳方法、乐观控制法和多版本并发控制等。
- 时间戳方法****给每一个事务盖上一个时标,即事务开始执行的时间。每个事务具有唯一的时间戳,并按照这个时间戳来解决事务的冲突操作。如果发生冲突操作,就回滚具有较早时间戳的事务,以保证其他事务的正常执行,被回滚的事务被赋予新的时间戳并从头开始执行。
- 乐观控制法认为事务执行时很少发生冲突,因此不对事务进行特殊的管制,而是让它自由执行,事务提交前再进行正确性检查。如果检查后发现该事务执行中出现过冲突并影响了可串行性,则拒绝提交并回滚该事务。乐观控制法又被称为验证方法(certifier)。
- 多版本并发控制(MultiVersion Concurrency Control, MVCC)是指在数据库中通过维护数据对象的多个版本信息来实现高效并发控制的一种策略。