第09章 数据恢复技术和并发控制

第9章 数据库恢复和并发控制本章要点事务基本概念定义事务的SQL语句性质数据库恢复恢复的定义、原则和方法故障的种类及恢复方法具有检查点的恢
复技术数据库镜像本章要点并发控制并发操作带来的数据不一致性封锁活锁和死锁并发调度的可串行性两段锁协议封锁的粒度9.1 事务9.
1.1 事务的基本概念所谓事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。订票：查询、
订位、交钱、出票转帐：转出、转入事务开始与结束可以由用户显式控制。如果没有显式定义事务，则由DBMS按缺省规定自动划分事务。在SQ
L中，定义事务的语句有三条：BEGIN TRANSACTIONCOMMIT（提交，将事务中所有对数据库的更新写回到磁盘上的物理数据
库中。）ROLLBACK（回滚，在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤消
，回滚到事务开始时的状态。）示例银行转帐：从A帐户过户1000￥到B帐户 read(A); A := A – 1000;
write(A); read(B); B := B + 1000; write(B);read(X)：从数据库传送
数据项X到事务的工作区中write(X)：从事务的工作区中将数据项X写回数据库举例BEGIN TRANSACTION
/ 定义转账事务开始 / SELECT @totalDeposit=total FROM AccountTable
WHERE accountNum=@
outAccount; IF @totalDeposit IS NULL / 账户不存在或账户中没有存款 /
ROLLBACK; IF @totalDeposit < 1000 / 账户账户存款不足 /
ROLLBACK; UPDATE account SET total=total-1000
WHERE ACCOUNTNUM = @outAc
count; / 修改转出账户，减去转出额 / UPDATE AccountTable SET total
=total + 1000 WHER
E accountNum =@inAccount;
/ 修改转入账户，增加转出额 /COMMIT;
/ 提交转账事务 /9.1.2 事务的性质原子性（Atomicity）事务中包含的所有操作要么全做，要么全不做原子性由恢复
机制实现一致性（Consistency）事务开始前，数据库处于一致性的状态事务结束后，数据库必须仍处于一致性状态事务执行的结果必须
是使数据库从一个一 致性状态变到另一个一致性状态一致性状态： 数据库中只包含成功事务提交的结果隔离性（Isolation）系统必须
保证事务不受其它并发执行事务的影响一个事务内部的操作及使用的数据对其他并发事务是隔离的持续性（Durability）一个事务一旦提
交之后，它对数据库的影响必须是永久的系统发生故障不能改变事务的持久性ACID 特性（Atomicity）（Consistency）
（Isolation）（Durability）A C I
DACID特性可能遭到破坏的因素事务在运行过程中被强行停止多个事务并行运行时，不同事务的操作交
叉执行事务在运行过程中被强行停止多个事务并行运行时，不同事务的操作交叉执行Phase 1Phase 2Phase 3事务A开始事务
A提交旅客A查询到剩余票信息旅客A买一张15日G1次7车5号车票，提交订单系统更新剩余票信息并将它存入数据库事务B开始事务B提交旅
客B查询到剩余票信息旅客B买一张15日G1次7车5号车票，提交订单系统更新剩余票信息并将它存入数据库9.2 数据库恢复技术故障是
不可避免的计算机硬件故障系统软件和应用软件的错误操作员的失误恶意的破坏故障的影响运行事务非正常中断破坏数据库数据库管理系统对故障的
对策DBMS提供恢复子系统保证故障发生后，能把数据库中的数据从错误状态恢复到某种逻辑一致的状态保证事务的ACID特性恢复技术是衡量
系统优劣的重要指标9.2.1 故障的种类1. 事务故障 事务故障是某个事务在运行过程中由于种种原因未运行至正常终点就终止了。
常见原因运算溢出并发事务发生死锁违反完整性限制1. 事务故障 恢复方法DBMS的恢复子系统要在不影响其他事务运行的情况下，强行回
滚（ROLLBACK）该事务。这类恢复操作称为事务撤消（UNDO）。2. 系统故障指造成系统停止运转的任何事件，使得系统要重新启动
。整个系统的正常运行突然被破坏所有正在运行的事务都非正常终止内存中数据库缓冲区的信息全部丢失外部存储设备上的数据未受影响系统故障的
常见原因操作系统或DBMS代码错误操作员操作失误特定类型的硬件错误（如CPU故障）突然停电恢复方法：系统故障的恢复是由系统在重新启
动时自动完成的，不需要用户干预。恢复子系统必须在系统重新启动时，让所有非正常终止的事务回滚，强行撤销（UNDO）所有未完成事务。对
已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，应将这些已提交的结果重新写到数据库。恢复子系统除需要撤
消所有未完成事务外，还需重做（REDO）所有已提交的事务3. 介质故障硬件故障使存储在外存中的数据部分丢失或全部丢失介质故障比前两
类故障的可能性小得多，但破坏性大得多介质故障的常见原因硬件故障磁盘损坏磁头碰撞操作系统的某种潜在错误瞬时强磁场干扰介质故障的恢复装
入数据库发生介质故障前某个时刻的数据副本装入相应的日志文件副本，重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库4
. 计算机病毒和人为破坏计算机病毒是一种人为的故障或破坏。由于用户有意或无意的操作也可能删除数据库中的有用的数据或加入错误的数据，
这同样会造成一些潜在的故障。 9.2.2 恢复的实现技术故障对数据库的影响数据本身被破坏；数据库没有被破坏，但数据可能不正确
，这是由于事务的运行被非正常终止造成的。恢复操作的基本原理恢复操作的基本原理：冗余利用存储在系统其它地方的冗余数据来重建数据库中已
被破坏或不正确的那部分数据恢复的实现技术复杂一个大型数据库产品，恢复子系统的代码要占全部代码的10%以上恢复机制涉及的关键问题如何
建立冗余数据数据转储（backup）登录日志文件（logging）如何利用这些冗余数据实施数据库恢复分类定义：所谓转储 即DBA周
期性地将整个数据库复制到另一个介质上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。1. 数据转储静态转储 在系统中无运
行事务时进行的转储操作。即转储操作开始的时刻，数据库处于一致性状态，而转储期间不允许（或不存在）对数据库的任何存取、修改活动。动态
转储是指转储期间允许对数据库进行存取或修改。即转储和用户事务可以并发执行。海量转储与增量转储海量转储: 每次转储全部数据库增量转储
: 只转储上次转储后更新过的数据2. 登记日志文件一、日志文件的内容二、日志文件的作用三、登记日志文件的原则日志文件的内容日志文
件是用来记录事务对数据库的更新操作的文件。格式以记录为单位以数据块为单位日志文件的内容以记录为单位每条日志记录的内容: 事务标识
更新操作类型 操作对象（记录内部标识） 更新前数据的旧值 更新后数据的新值日志文件的内容以数据块为单位每条日志记录的内容: 事务标
识 更新前的数据块 更新后的数据块日志文件的作用进行事务故障和系统故障恢复动态转储方式中的数据库恢复静态转储方式中，协助后备副本进
行故障恢复利用日志文件恢复登 记 日 志 文 件利用日志文件恢复登记日志文件利用日志文件恢复登记日志文件利用日志文件恢复登 记 日
志 文 件重 新 登 记 日 志 文 件数据库恢复到一致的状态登记日志文件的原则登记的次序严格按并行事务执行的时间次序必须先写日
志文件，后写数据库写日志文件操作：把表示这个修改的日志记录 写到日志文件写数据库操作：把对数据的修改写到数据库中9.2.3
故障恢复的策略1 事务故障的恢复1 事务故障的恢复234对更新操作执行逆操作继续反向扫描日志文件依次类推1反向扫描日志文件1
事务故障的恢复234对更新操作执行逆操作继续反向扫描日志文件依次类推1反向扫描日志文件1 事务故障的恢复234对更新操作执行逆操作
继续反向扫描日志文件依次类推1反向扫描日志文件2 系统故障的恢复系统故障造成数据库不一致状态的原因一些未完成事务对数据库的更新已
写入数据库一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库恢复方法Undo 故障发生时未完成的事务Redo 已完成的事务
系统故障的恢复由系统在重新启动时自动完成，不需要用户干预系统故障的恢复步骤234创建REDO队列和UNDO队列反向扫描日志文件正向
扫描日志文件1正向扫描日志文件系统故障的恢复步骤234创建REDO队列和UNDO队列反向扫描日志文件正向扫描日志文件1正向扫描日志
文件系统故障的恢复步骤234创建REDO队列和UNDO队列反向扫描日志文件正向扫描日志文件1正向扫描日志文件系统故障的恢复步骤23
4创建REDO队列和UNDO队列反向扫描日志文件正向扫描日志文件1正向扫描日志文件3 介质故障的恢复（1） 装入最新的后备数据库副
本，使数据库恢复到最近一次转储时的一致性状态。对于静态转储的数据库副本，装入后数据库即处于一致性状态对于动态转储的数据库副本，还须
同时装入转储时刻的日志文件副本，利用与恢复系统故障相同的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。（2） 装入有
关的日志文件副本，重做已完成的事务。首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入REDO队列。然后正向扫描日志文件
，对REDO队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。4. 具有检查点的恢复技术系统故障恢复时的问题：
搜索整个日志将耗费大量的时间很多需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了，然而恢复子系统又重新执行了这些
操作，浪费了大量时间解决办法：DBMS定时设置检查点在检查点时刻才真正做到把对数据库的修改写到磁盘。当数据库需要恢复时，只有检查点
后面的事务需要恢复。在日志文件中增加一类新的记录 —— 检查点记录，内容包括：建立检查点时刻所有正在执行的事务清单。这些事务最近一
个日志记录的地址。 增加一个重新开始文件内容：记录各个检查点记录在日志文件中的地址 恢复子系统在登录日志文件期间动态地维护日志具体
步骤是： ①将当前日志缓冲中的所有日志记录写入磁盘的日志文件上； ②在日志文件中写入一个检查点记录； ③将当前数据缓冲的所有
数据记录写入磁盘的数据库中； ④把检查点记录在日志文件中的地址写入一个重新开始文件。不要REDOTc（检查点）Tf（故障点）12
345REDOUNDOREDOUNDO恢复策略检查点方法的恢复算法234创建UNDO队列和REDO队列正向扫描日志文件执行UNDO
和REDO操作1找到最后一个检查点检查点方法的恢复算法234创建UNDO队列和REDO队列正向扫描日志文件执行UNDO和REDO操
作1找到最后一个检查点检查点方法的恢复算法234创建UNDO队列和REDO队列正向扫描日志文件执行UNDO和REDO操作1找到最后
一个检查点检查点方法的恢复算法234创建UNDO队列和REDO队列正向扫描日志文件执行UNDO和REDO操作1找到最后一个检查点5
. 数据库镜像介质故障是对系统影响最为严重的一种故障，严重影响数据库的可用性介质故障恢复比较费时为预防介质故障，DBA必须周期性地
转储数据库提高介质故障时数据库可用性的解决方案数据库镜像（Mirror）DBMS自动把整个数据库或其中的关键数据复制到另一个磁盘上
DBMS自动保证镜像数据与主数据的一致性数据库镜像的用途没有出现故障时可用于并发操作一个用户对数据加排他锁修改数据时，其他用户可以
读镜像数据库上的数据出现介质故障时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本updateupda
teupdatereadreadread没有出现故障时updateupdateupdatereadreadread恢复出现介质故障
时9.3 常见数据库的恢复技术9.3.1 SQL Server数据库的恢复技术1. 数据转储策略转储操作在SQL Serv
er中被称为“备份”。在制定备份策略之前，需要考虑的内容包括备份内容、备份频率和备份数据的存储介质。备份内容包括数据库和日志文件。
除了用户数据库之外，几个重要的系统数据库如master、msdb、model等都应该备份。应根据数据库内容的重要性确定备份频率，1
. 数据转储策略只备份数据库优点：操作和规划简单，在恢复时只需一步就可以将数据库恢复到以前的状态。一般只用在数据重要性不是太高，
或是数据更新缓慢的数据库系统中。可以采用完全备份和增量备份两种方式。完全备份可以备份整个数据库，包含用户表、系统表、索引、视图和存
储过程等所有数据库对象。增量备份只备份上次全面备份以来，数据库发生的一系列新变化。1. 数据转储策略同时备份数据库和事务日志 所
有在意外发生时已经完成的事务都将被恢复，只有在意外发生时还没有提交的事务会丢失。使用这种策略可以将数据库恢复到发生意外前的状态，从
而将数据损失减小到最小。如果数据至关重要，或数据库更新非常频繁，适合采用这种策略。由于备份事务日志通常需要较少的备份资源，所以一般
应当频繁备份事务日志，减小丢失数据的可能。典型的备份策略采用完全备份，只备份数据库两个全备份之间的时间段发生故障，数据会丢失，只能
恢复到上一个全备份的数据。典型的备份策略全备份+日志备份在全备份之间加入日志备份，这样可以把备份时间点缩小到更小的粒度。例如，每一
个小时或者半个小时做一次日志备份。如果发生故障，操作恢复的时间会比较长。典型的备份策略 全备份+差异备份+日志备份 在全备份之间加
入差异备份，差异备份之间有日志备份。至于选择哪一种备份策略，要根据实际的情况灵活运用。2. 数据转储和恢复的SQL语句数据转储B
ACKUP DATABASE|LOG { database_name |@database_name_var} TO ckup_device_name>[，..n] [WITH DIFFERENTIAN]数据恢复RESTORE DATABAS
E { database_name | @database_name_var } [ FROM < backup_dev
ice > [ ,...n ] ] [ WITH REPLACE]3. SQL Server的检查点SQL Serve
r支持具有检查点的恢复技术。SQL Server提供有两种方法建立检查点：由SQL Server自动执行的检查点由数据库所有者或D
BA调用CHECKPOINT命令强制执行的检查点。9.3.2 Oracle数据库的恢复技术1．导出/导入利用Export可将数据
从数据库中提取出来；利用Import则可将提取出来的数据送回Oracle数据库中去。数据导出的过程是数据导入的逆过程，它们的数据流
向不同。1．导出/导入 简单导出/导入 增量导出/导入“完全型”增量导出“增量型”增量导出“累计型”增量导出数据库管理员可以综合使
用数据导出的三个不同方式，制定一个数据备份的策略和计划，合理高效地完成数据库的备份和恢复。2．冷备份冷备份必须在数据库已经正常关闭
的情况下进行。优点它只需拷贝文件，是非常快速的备份方法，容易归档恢复时只需将文件再拷贝回去，整体维护工作量较小。不足单独使用时，只
能提供到“某一时间点上”的恢复；在实施备份的全过程中，数据库必须处于关闭状态，不能做其它工作；如果拷贝到磁带等其它外部存储设备上，
速度会很慢。冷备份的数据库不能按数据表或按用户恢复。通常冷备份中必须拷贝的文件包括所有数据文件、所有控制文件、所有联机REDO L
OG文件、Init.ora文件。3．热备份热备份在数据库正常运行的情况下进行，要求数据库在Archivelog方式下操作，并需要大
量的存储空间。一旦数据库运行在Archivelog状态下，就可以做备份了。热备份的命令文件由三部分组成: 数据文件 备份归档log
文件 用alter database backup controlfile命令来备份拷贝文件3．热备份热备份的优点可在表空间或数据
文件级备份，备份时间短，备份时数据库仍可正常使用。热备份可以非常精确的备份表空间级和用户级的数据，由于它是根据归档日志的时间轴来备
份恢复的，理论上可以恢复到前一个操作，甚至就是前一秒的操作。热备份可对几乎所有数据库实体作恢复，恢复的过程也非常快速，在大多数情况
下数据恢复并不会影响数据库的正常工作。热备份的不足热备份的过程不能出错热备份过程的维护比较困难。4．日志每一个Oracle数据库实
例都提供日志，记录数据库中所作的全部修改。每一个运行的Oracle数据库实例相应地有一个在线日志，归档（离线）日志是可选择的。Or
acle数据库可运行在NOARCHIVELOG方式或ARCHIVELOG方式两种不同方式下。数据库在NOARCHIVELOG方式下
运行时，不能进行在线日志的归档；在ARCHIVELOG方式下运行时，可实施在线日志的归档。9.4 并发控制多事务执行方式(1)事
务串行执行（serial access）每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行不能充分利用系统资源，发
挥数据库共享资源的特点(2)交叉并发方式（interleaved concurrency）事务的并行执行是这些并行事务的并行操作轮
流交叉运行是单处理机系统中的并发方式，能够减少处理机的空闲时间，提高系统的效率T1 T2
T3(3)同时并发方式（simultaneous concurrency）多处理机系统中，每个处理机可以运行一个事
务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行最理想的并发方式，但受制于硬件环境T1 T2
T39.4.1 并发操作带来的问题可能会存取和存储不正确的数据，破坏事务的隔离性和数据库的一致性
并发控制机制的任务对并发操作进行正确调度保证事务的隔离性和一致性保证数据库的一致性并发操作带来的数据不一致性丢失修改（lost u
pdate）不可重复读（non-repeatable read）读“脏”数据（dirty read）1. 丢失修改举例（假设）旅客
A 通过网络购票，要买一张15日北京到上海的G1次高速列车的一等座车票，旅客A得到剩余票信息； 几乎在同时，旅客B 也通过网络购票
，也要买一张15日北京到上海的G1次高速列车的一等座车票， 用户B从另一台计算机查到了同样的剩余票信息； 旅客A买了一张15日G1
次7车厢5号车票，旅客A提交订单、系统更新剩余票信息并将它存入数据库； 这时旅客B不知道旅客A已经购买了15日G1次7车厢5号车票
，使旅客B也也提交了一张15日G1次7车厢5号车票，系统再次更新剩余票信息并将它存入数据库（重复了旅客A提交订单时已经做过的更新）
。总的效果：15日G1次7车厢5号车票卖了两次。原因：允许了旅客B在过时的信息基础上去更新数据库，而没有迫使他去看最新的信息。2.
不可重复读三类不可重复读事务1读取某一数据后：1. 事务2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。2. 事务
2删除了其中部分记录，当事务1再次读取数据时，发现某些记录神秘地消失了。3. 事务2插入了一些记录，当事务1再次按相同条件读取数据
时，发现多了一些记录。后两种不可重复读有时也称为幻影现象（phantom row）3. 读“脏”数据三种数据不一致产生的主要原因:
并发操作破坏了事务的隔离性并发控制就是要用正确的方式调度并发操作，使一个事务的执行不受其他事务的干扰，从而避
免造成数据的不一致性，保证事务的隔离性。并发控制主要技术：封锁封锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致。9.4.
2 封锁1. 封锁的概念封锁就是事务T在对某个数据对象操作之前，先向系统发出请求，对其加锁。在事务T释放它的锁之前，其他
的事务不能更新此数据对象。基本封锁类型排它锁又称为写锁（Exclusive lock，简记为X锁）若事务T对数据对象A加上X锁，则
只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。共享锁又称为读锁（Share lock，简记为S
锁）若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。2.
封锁协议在事务并发操作对数据对象加锁时，还需要约定一些规则，即何时申请X锁或S锁、持锁时间、何时释放等，称这些规则为封锁协议。
对封锁方式规定不同的规则，就形成了各种不同的封锁协议 。2. 封锁协议一级封锁协议事务在修改数据R之前必须先对其加X锁，直到事务
结束才释放。事务结束包括正常结束(COMMIT)和非正常结束(ROLLBACK)。一级封锁协议可以防止丢失修改，并保证事务T是可恢
复的。在一级封锁协议中，如果仅仅是读数据不对其修改，是不需要加锁的，所以它不能保证可重复读和不读“脏数据”。在一级封锁协议中，如果
仅仅是读数据不对其修改，是不需要加锁的，所以它不能保证可重复读和不读“脏数据”。2. 封锁协议二级封锁协议在一级封锁协议的基础上
，加上事务T在读数据R之前必须先对其加S锁，读完后即可释放S锁。二级封锁协议除了防止丢失修改，还可以进一步防止读“脏数据”。在二级
封锁协议中，由于事务T读完了数据后即可释放S锁，所以不能保证可重复读。2. 封锁协议三级封锁协议在一级封锁协议的基础上，加上事务
T在读数据R之前必须先对其加S锁，直到事务结束时释放S锁。三级封锁协议除了防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复
读。3 . 活锁和死锁活锁定义：指某个事务由于请求封锁但总也得不到锁而处于长时间的等待状态。解决方法：先来先服务死锁 T1
T2 获得 Xlock R1...申请 Xlock R2等待等待等待...获得 Xlock R2..申请 Xloc
k R1等待等待.在同时处于等待状态的两个或多个事务中，每个事务封锁一部分数据资源，同时等待其他事务释放数据资源。解决死锁的方法两
类方法采取一定措施来预防死锁的发生采用一定手段定期诊断系统中有无死锁，若有则解除之死锁的预防产生死锁的原因是两个或多个事务都已封锁
了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。预防死锁的发生就是要破坏产生死锁的条件。预防死锁的方
法 一次封锁法 顺序封锁法一次封锁法是要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。需要将以后要用到的全部数
据加锁，这势必扩大了封锁的范围，从而降低了系统的并发度。同时，由于数据库中数据是不断变化的，原来不要求封锁的数据，在执行过程中可能
会变成封锁对象，所以很难事先精确地确定每个事务所要封锁的数据对象。顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序
实行封锁。存在的主要问题是维护成本高。数据库系统中可封锁的数据对象极其众多并且随数据的插入、删除等操作而不断地变化事务的封锁请求可
以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。死锁的诊断与解除允许死锁发
生解除死锁由DBMS的并发控制子系统定期检测系统中是否存在死锁一旦检测到死锁，就要设法解除死锁的检测超时法如果一个事务的等待时间超
过了规定的时限，则认为发生了死锁。等待图法使用“事务等待图” 来判断是否存在死锁。每个结点表示正在运行的事务；每条有向边表示事务等
待的情况。如果发现图中存在回路，则表示系统中出现了死锁。事务等待图DBMS对并发事务不同的调度可能会产生不同的结果什么样的调度是正
确的？9.4.3 并发调度的可串行性可串行化(Serializable)调度多个事务的并发执行是正确的，当且仅当其结果与按某一次
序串行地执行这些事务时的结果相同，称这种调度策略为可串行化的调度可串行性(Serializability)是并发事务正确调度的准则
一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度 串行调度不可串行化的调度和可串行化的调度 9.4.4 两段锁协议两
段锁协议的内容1. 在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁2. 在释放一个封锁之后，事务不再获得任何其他封锁
。“两段”锁的含义事务分为两个阶段 第一阶段是获得封锁，也称为扩展阶段； 第二阶段是释放封锁，也称为收缩阶段。事务1的封锁序列：S
lock(A)→Slock(B)→Xlock(C)→Unlock(A) →Unlock(C)→Unlock(B)事务2的封锁序列：
Slock(A)→Unlock(A)→Slock(B)→Xlock(C) →Unlock(C)→Unlock(B)事务1遵守两段锁
协议，而事务2不遵守两段协议。例并行执行的所有事务均遵守两段锁协议，则对这些事务的所有并行调度策略都是可串行化的。 所有遵守两段锁
协议的事务，其并行执行的结果一定是正确的事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件可串行化的调度中，不一定所有事务
都必须符合两段锁协议。两段锁协议与防止死锁的一次封锁法一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行
，因此一次封锁法遵守两段锁协议但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁遵
守两段锁协议的事务发生死锁T1Slock B读B=2??Xlock A等待等待T2??Slock A读A=2?Xlock B等待9
.4.5 封锁的粒度X锁和S锁都是加在某一个数据对象上的封锁的对象：逻辑单元，物理单元 例：在关系数据库中，封锁对象：
逻辑单元: 属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等物理单元：页（数据页或索引页）、物理记录等封锁对象可以很
大也可以很小 例： 对整个数据库加锁 对某个属性值加锁封锁对象的大小称为封锁的粒度(Granular
ity)选择封锁粒度原则封锁粒度与系统的并发度和并发控制的开销密切相关。封锁的粒度越大，数据库所能够封锁的数据单元就越少，并发度就
越小，系统开销也越小；封锁的粒度越小，并发度较高，但系统开销也就越大1. 多粒度封锁和多粒度树多粒度封锁(Multiple Gr
anularity Locking)在一个系统中同时支持多种封锁粒度供不同的事务选择同时考虑封锁开销和并发度两个因素，适当选择封锁
粒度需要处理多个关系的大量元组的用户事务：以数据库为封锁单位需要处理大量元组的用户事务：以关系为封锁单元只处理少量元组的用户事务：
以元组为封锁单位多粒度树以树形结构来表示多级封锁粒度根结点是整个数据库，表示最大的数据粒度叶结点表示最小的数据粒度例：四级粒度树。
根结点为数据库，数据库的子结点为关系，关系的子结点为元组。多粒度封锁协议允许多粒度树中的每个结点被独立地加锁对一个结点加锁意味着这
个结点的所有后裔结点也被加以同样类型的锁在多粒度封锁中一个数据对象可能以两种方式封锁：显式封锁和隐式封锁显式封锁: 直接加到数据对
象上的封锁。隐式封锁: 由于其上级结点加锁而使该数据对象加上了锁。对某个数据对象加锁时系统检查的内容 该数据对象有无显式封锁与之冲
突 所有上级结点检查本事务的显式封锁是否与该数据对象上的隐式封锁冲突：(由上级结点封锁造成的）所有下级结点看上面的显式封锁是否与本
事务的隐式封锁（将加到下级结点的封锁）冲突。2 意向锁引进意向锁（intention lock）目的提高对某个数据对象加锁时系统的
检查效率对任一结点加基本锁，必须先对它的上层结点加意向锁如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁例：对任一元组 r
加锁，先对关系R加意向锁 事务T要对关系R加X锁, 系统只要检查根结点数据库和关系R是否已加了不相容的锁，不需要搜索和检查R中
的每一个元组是否加了X锁常用意向锁意向共享锁(Intent Share Lock，简称IS锁)意向排它锁(Intent Exclu
sive Lock，简称IX锁)共享意向排它锁(Share Intent Exclusive Lock，简称SIX锁)IS锁如果对
一个数据对象加IS锁，表示它的后裔结点拟（意向）加S锁。例：要对某个元组加S锁，则要首先对关系和数据库加IS锁IX锁如果对一个数据
对象加IX锁，表示它的后裔结点拟（意向）加X锁。例：要对某个元组加X锁，则要首先对关系和数据库加IX锁。SIX锁如果对一个数据对象
加SIX锁，表示对它加S锁，再加IX锁，即SIX = S + IX。例：对某个表加SIX锁，则表示该事务要读整个表（所以要对该表加
S锁），同时会更新个别元组（所以要对该表加IX锁）。锁的强度锁的强度是指它对其他锁的排斥程度一个事务在申请封锁时以强锁代替弱锁是安
全的，反之则不然具有意向锁的多粒度封锁方法申请封锁时应该按自上而下的次序进行；释放封锁时则应该按自下而上的次序进行 9.
5 常见数据库的 并发控制技术9.5.1 SQL Server的封锁方式SQL Server里的封锁控制由一个内部的锁管理器进
程实现。锁管理器负责决定锁类型(共享锁，排它锁等)和锁粒度(行，页和表等)。SQL Server提供三种级别的物理锁行锁(row-
level lock)页锁(page lock)表锁(table lock)。SQL Server提供了多粒度锁。在事务执行过程中
，SQL Server自动为事务选择合适的资源封锁模式和封锁资源的粒度。9.5.1 SQL Server的封锁方式锁管理器使用的
封锁类型除了基本的共享锁和排它锁以外，还有更新锁、意向锁和模式锁。更新锁是为修改操作提供的页级排它锁；模式锁分为模式静态锁和模式修
改锁，当禁止修改模式时，使用静态锁；修改表结构或索引时，使用修改锁。一般情况下，SQL Server能自动提供加锁功能，不需要用户专门设置。锁管理器基于事务类型来选择锁的类型。例如，create index语句会封锁整个表，update语句会封锁一行或多行或整个表。在SQL Server中可以利用企业管理器浏览数据库中锁的信息。也可以利用系统存储过程sp_lock查看系统或指定进程对资源的封锁情况。sp_lock的语法格式为： sp_lock [spid1] [,spid2]其中，spid1、spid2是进程标识号。指定spid1、spid2参数时，SQL Server显示这些进程的封锁情况，否则显示整个系统的封锁情况。9.5.2 Oracle的封锁方式Oracle的封锁包括内部锁DDL锁DML锁DML锁三种封锁方式共享锁（SHARE）独占锁（EXCLUSIVE）共享更新锁（SHARE UPDATE）9.5.2 Oracle的封锁方式Oracle通过具有意向锁的多粒度封锁机制进行并发控制，保证数据的一致性。在Oracle系统中能自动发现死锁，并选择代价最小即完成工作量最少的事务予以撤消，释放该事务所拥有的全部锁，让其它的事务继续工作下去。9.6 小结如果数据库只包含成功事务提交的结果，就说数据库处于一致性状态。保证数据一致性是对数据库的最基本的要求。事务是数据库的逻辑工作单位DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性恢复中最经常使用的技术：数据库转储和登记日志文件恢复的基本原理：利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库提高恢复效率的技术检查点技术可以提高系统故障的恢复效率可以在一定程度上提高利用动态转储备份进行介质故障恢复的效率镜像技术镜像技术可以改善介质故障的恢复效率数据库的并发控制以事务为单位数据库的并发控制通常使用封锁机制两类最常用的封锁活锁和死锁并发控制机制调度并发事务操作是否正确的判别准则是可串行性并发操作的正确性则通常由两段锁协议来保证。两段锁协议是可串行化调度的充分条件，但不是必要条件封锁的粒度多粒度树多粒度封锁思考题在学习了事务管理和并发控制后，讨论应该如何设计事务（设计事务时要考虑哪些问题）？