《数据库事务管理》PPT课件.ppt

数据库系统基础教程（第2版） 叶小平 汤 庸 汤 娜 潘 明 编著 普通高等教育“十一五”国家级规划教材 清华大学出版社 1.事务概念 事务是DBMS中操作的基本执行单位，事务本身 就是构成单一逻辑工作单元的数据库操作的有限 序列。操作序列中的操作要么全做，要么全不做 ，整个序列是一个不可分割的操作单位。 第7章 数据库事务管理 7.1事务与事务管理 7.1.1事务概念与ACID性质：概念 2事务性质（ ACID ） （1）原子性（Atomicity） 一个事务对于数据所有操作是不可分割整体，这些操作要 么全执行，要么全不执行。 原子性是事务概念本质体现和基本要求。 7.1.1 事务概念与ACID性质 2事务性质（ ACID ） （2）一致性（Consistency） 数据库中数据不因事务执行而受到破坏， 事务执行结果应使数据库由一种一致性达 到另一种新的一致性。 一致性意义在于保证数据完整性。 7.1.1 事务概念与ACID性质 （3）隔离性（Isolation） 事务并发执行与这些事务单独执行的结果 一样。在多事务并发执行时，各事务不必 关心其它事务的执行，如同在单个用户环 境下执行一样。 隔离性意义在于是事务并发控制技术基础 。 7.1.1 事务概念与ACID性质 （4）持久性（Durability） 事务对数据的更新应永久地反映在数据库 中。事务一旦完成全部操作后，它对数据 库所有更新结果将永久保留，即使以后发 生故障也应保留相应结果。 持久性意义在于保证数据的故障恢复。 7.1.1 事务概念与ACID性质 7.1.1 事务概念与ACID性质 1. SQL中的事务处理语句 事务开始语句：START TRANSACTION语句 事务提交语句：COMMIT语句 存储点语句：SAVEPOINT语句 事务回滚语句：ROLLBACK语句 7.1.2 SQL对事务管理的支持 2. 事务提交与回滚基本方式 显式方式： 通过COMMIT和ROLLBACK语句明 显指出提交或回滚有关事务。 隐式方式： CREATE TABLE、DROP TABLE 、CREATE VIEW，CREATE INDEX等创建语句 在执行后即刻导致相关事务的提交。 自动方式： 定期提交完成的事务。 7.1.2 SQL对事务管理的支持 3.事务内容的两种类型 只读型（Read Only） 读写型（Read/Write） 7.1.2 SQL对事务管理的支持 事务并发执行是数据共享性重要保证，并 发执行应当加以适当控制，否则会出现数 据不一致，破坏数据库一致性。为在并发 执行过程中保持一致性，需应用事务概念 讨论并发控制技术。 7.2 并发控制技术 1.串行执行与并发执行 在事务活动过程中，只有当一个事务完全结束 ，另一事务才开始执行，这种执行方式称为事 务的串行执行或串行访问。 在事务执行过程中，如果DBMS同时接纳多个 事务，使得事务在时间上可以重叠执行，这种 执行方式称为事务的并发执行或并发访问 7.2.1 事务的并发执行 两类并发执行方式 交叉并发执行：在单CPU系统中，同一时间只 能有一个事务占用CPU，实际情形是各个并发执 行的事务交叉使用CPU，这种并发方式称为交叉 并发执行或分时并发执行。 同时并发执行：在多CPU系统中，多个并发执 行的事务可以同时占用系统中的CPU，这种方式 称为同时并发执行。 7.2.1 事务的并发执行 2.并发执行的优势 改善系统资源利用率 改善短事务响应时间 7.2.1 事务的并发执行 在同一时刻，多个用户存取同一数据，由 于使用时间相互重叠和使用方式彼此影响 ，如对并发操作不加以适当控制，就可能 引发数据不一致问题，导致错误结果，使 数据库由于并发操作错误而出现故障。 7.2.2 并发执行引发不一致 （1）丢失更新 丢失更新是指两个事务T1和T2从数据库读 取同一数据并进行更新，其中事务T2提交 的更新改结果破坏了事务T1提交的更新结 果，导致了事务T1的更新被丢失。丢失更 新是由于两个事务对同一数据并发地进行 写入操作所引起的，因而称为写-写冲突 7.2.2 并发执行引发不一致 （2）读“脏”数据 读“脏”数据是指事务T1将数据a更新成数据b，然 后将其写入磁盘；此后事务T2读取该更新后的数 据，即数据b；接下来T1因故被撤销，使得数据b 恢复到了原值a。这时，T2得到的数据就与数据 库内的数据不一致。这种不一致或者不存在的数 据通常就称为“脏”数据。 7.2.2 并发执行引发不一致 （3）不可重复读取 不可重复读是指当事务T1读取数据a后，事 务T2进行读取并进行更新操作，使得T1再 读取a进行校验时，发现前后两次读取值发 生了变化，从而无法再读取前一次读取的 结果。 7.2.2 并发执行引发不一致 不可重复读包括3种情形。 事务T1读取某一数据后，事务T2对其进行了修改，当事 务T1再次读该数据时，得到与前一次不同的值。图8-5中 （c）说明的就是这种情况。 事务T1按一定条件从数据库中读取某些数据记录后，事 务T2删除了其中的部分记录，当事务T1再次按照相同条 件读取该数据时，发现某些记录已经不存在了。 事务T1按一定条件从数据库中读取某些数据记录后，事 务T2插入了一些记录，当事务T1再次按照统一条件读取 数据，就会发现多出了某些数据 7.2.2 并发执行引发不一致 7.2.2 并发执行引发不一致 1.事务并发执行的调度 在数据库应用中，经常存在多个事务执行过程。 由于每个事务含有若干有序的操作，当这些事务 处于并发状态时，DBMS就必须对这些操作的执 行顺序做出安排，即需要进行“调度”。 如果数据库在某时刻存在并发执行的n个事务之集 ，对这n个事务所有操作一个顺序安排称为对该并 发执行事务集的一个调度（Schedule）。 7.2.3 并发执行正确性准则 2.并发操作正确性准则可串行化准则 当数据库有多个事务进行操作时，如果对 数据库进行的操作以事务为单位，多个事 务按顺序依次执行，即一个事务执行完全 结束之后，另一个事务才开始，这种执行 方式就是串行调度。 7.2.3 并发执行正确性准则 对于一个并发事务集来说，如果一种调度与一种 串行调度等价，则称该调度可串行化，这种执行 称为并发事务的可串行化，采用相应技术称之为 并发控制（Concurrent Control）技术。DBMS 以可串行化作为并发控制正确性准则，其中并发 控制机构的任务就是调度事务的并发执行，使得 这个事务等价于一个串行调度。 7.2.3 并发执行正确性准则 串行执行、并发执行（不正确）以及并发 执行可以串行化（正确）的例子。 例7-1 以银行转账为例。事务T1从账号A（ 初值为20000）转10000到账号B（初值为 20000），事务T2从账号A转10%的款项到 账号B，T1和T2具体执行过程如下： 7.2.3 并发执行正确性准则 7.2.3 并发执行正确性准则 在串行调度（1）中，执行T1后的数据 A=10000，B=30000。T2读取这样的数据 A，B，得到Temp=A*0.1=1000，A：=A- Temp=9000，B：=B+Temp=31000。最 终，数据库写入数据A=9000，B=31000。 7.2.3 并发执行正确性准则 在串行调度（2）中，执行T2后的数据 Temp=A*0.1=2000，A：=A-Temp=18000；B ：=B+Temp=22000。T1读取这样的数据A和B， 得到A：=A-10000=8000， B： =B+10000=32000。最终数据库写入数据 A=8000，B=32000 下面给出如下图所示的两种并发调度方案。 7.2.3 并发执行正确性准则 7.2.3 并发执行正确性准则 通过并发执行调度（1），得到数据 A=9000，B=31000，与先T1再T2结果相同 ，因此调度（1）是可串行化调度。通过并 发执行调度（2），得到数据A=18000， B=32000，与T1再T2和先T2再T1的结果都 不相同，因此调度（1）是非可串行化调度 。 7.2.3 并发执行正确性准则 事务并发控制是对多事务并发执行中所有操作按 照正确方式进行调度，避免造成数据不一致性， 使得一个用户事务执行不受其他事务干扰。并发 控制技术是采用封锁机制，其基本思想是如果事 务T要修改数据A，在读A前先封锁A，此时，其 他事务不能读和修改A，直到T修改并写回A并解 除对A封锁为止。 7.2.4 并发执行基本技术 1.封锁概念 当一个事务T需要对某些数据对象进行操作（读/ 写）时，须向系统提出申请，对其加以封锁；在 获得加锁后，即具有对此数据一定操作与控制权 限，而其他事务不能对加锁数据随意操作。 当事务T操作完成之后即释放锁，此后数据即可为 其他事务操作服务。 7.2.4 并发执行基本技术 2.两种封锁类型 （1）排它锁 排它锁（eXclusive Lock）又称为写锁或X 锁，其含义是：事务T对数据A加X锁后，T 可以对加X锁的A进行读写，而其它事务只 有等到T解除X锁之后，才能对A进行封锁 和操作（包括读写）。 7.2.4 并发执行基本技术 （2）共享锁 共享锁（Sharing Lock）又称为读锁或S 锁。其含义是：事务T对数据A加S锁之后 ，T可以读A但不能写A；同时其它事务可 以对A加S锁但不能加X锁。 7.2.4 并发执行基本技术 7.2.4 并发执行基本技术 排它锁和共享锁的控制方式可以用图7-8所示的相容矩阵 表示。其中，Y=YES，表示相容的请求；N=NO，表示不 相容的请求。 7.2.4 并发执行基本技术 3. 封锁粒度 逻辑粒度： 属性（值），属性（值）集合； 元组； 关系表； 数据库。 物理粒度： 物理页面； 索引。 7.2.4 并发执行基本技术 1三级封锁协议与数据一致性 （1）一级封锁协议 一级封锁协议的内容是：事务T在对数据A写操作 之前，必须对A加X锁；保持加锁状态直到事务结 束（包括Commit与Rollback）方可释放加在A上 的X锁。 以图7-5（a）为例，对它做一级封锁后即可避免 修改丢失，如图7-9所示。 7.2.5 封锁协议 7.2.5 封锁协议 （2）二级封锁协议 考虑下面封锁方式：事务T读取数据A前先对A加S锁，读 完后即释放加在A上S锁。 此种封锁方式与一级封锁协议联合构成二级封锁协议。 二级封锁协议包含一级封锁协议内容。按照二级封锁协议 ，事务对数据A做读、写操作时使用X锁，从而防止了丢 失数据；做读操作时使用S锁，从而防止了读脏数据。以 图8-5（b）为例，对它做二级封锁，即可防止脏读，如图 8-10所示。 7.2.5 封锁协议 7.2.5 封锁协议 （3）三级封锁协议 考虑封锁方式：事务T在读数据A之前须先 对A加S锁，到事务结束释放加在A上S锁。 上述封锁方式与一级封锁协议联合构成三 级封锁协议。 7.2.5 封锁协议 按照三级封锁协议的概念，由于包含一级封锁协 议，所以防止了丢失修改；同时由于包含了二级 封锁协议，防止了读脏数据；另外由于在对数据 A做写时以X锁封锁，做读时以S锁封锁，这两种 锁都是直到事务结束后才释放，由此就防止不可 重复读。所以三级封锁协议同时防止并发执行中 的3类问题。以图7-5（c）为例，对它做三级封锁 ，防止了不可重复读，如图7-11所示。 7.2.5 封锁协议 7.2.5 封锁协议 三级封锁协议机制总结如图7-12所示，其中，“+”表示具 有该项特征，“”表示不具有相应特征。 7.2.5 封锁协议 2两段封锁协议与可串行化调度 由前述可知，实行三级封锁协议就可以防 止事务并发执行3类错误发生，但防止错误 发生并不能保证并发调度是可串行化的。 为了保证调度一定等价于一个串行调度， 必须使用其他附加规则来限制封锁的操作 时机。参考下面例子： 7.2.5 封锁协议 例7-2 设有两个事务T1和T2，其初始值为 ：x=20，y=50。图7-13表示T1和T2都遵循 了二级封锁协议基本要求。 7.2.5 封锁协议 7.2.5 封锁协议 如果先执行T1后执行T2得到串行结果为x=50， y=80；如果先执行T2后执行T1得到串行结果 x=70，y=50。如图7-13所示。如果我们再按图8- 14所示调度方式进行并发执行，其中T1、T2满足 二级封锁协议（注意，封锁协议本身与并行调度 无关），得到结果为x=50，y=50，这说明此时调 度不是可串行化的。 7.2.5 封锁协议 7.2.5 封锁协议 问题出在哪里呢？按照二级封锁协议，所 有在事务中申请的X锁必须在事务结束后才 能释放，但其S锁却可以较早解除。一个事 务如果在解除一个封锁之后，继续获得另 一个封锁，就有可能出现错误，不能够实 现可串行化。 7.2.5 封锁协议 在三级封锁协议中，所有事务执行过程中申请的 锁必须在事务结束后才能释放，即使说，事务必 须将锁使用分为申请和释放两个阶段， 扩展阶段：申请并获得封锁。在此阶段中，事务 可以申请其整个执行过程中所需要数据的锁。 收缩阶段：释放所有原申请并且获得的锁。 7.2.5 封锁协议 已经证明，如果在一个并行调度中所有事 务的封锁满足这样两个阶段要求，该调度 一定是可串行化的。这就意味着，满足三 级封锁协议的并行调度是可串行化的。 7.2.5 封锁协议 实际上，上述封锁两个阶段还可单独定义，依照 上述扩展和收缩阶段设置封锁的方法称为两段封 锁协议（Two-phase Locking Protocol）。 扩展阶段：可以加新锁但不可释放锁； 收缩阶段：可以释放锁但不可加新锁。 两段封锁协议实际上规定了在一个事务中所有的 封锁操作必须出现在第一个释放锁操作之前。 7.2.5 封锁协议 遵守两段封锁协议的封锁示例可表示如下： T：Slock A Slock B Xlock C Unlock A Unlock B Unlock C 7.2.5 封锁协议 不遵守两个阶段封锁协议的封锁序列可以示例表 示如下： T：Slock A Unlock A Slock B Xlock C Unlock C Unlock B 按照两段封锁协议，例7-2中的事务T1和T2操作 进行适当调整，就得到如图7-15所示封锁情形T1 和T2： 7.2.5 封锁协议 此时，按照图7-16所示并发调度，就可得到相应可串行化结果。 7.2.5 封锁协议 7.2.5 封锁协议 1封锁协议带来的新问题 活锁 (Live Lock) ：在封锁过程中，系统可能 使某个事务永远处于等待状态，得不到封锁机会 。 死锁（Dead Lock）： 若干个事务都处于等待 状态，相互等待对方解除封锁，结果造成这些事 务都无法进行，系统进入对锁的循环等待。 7.2.6 死锁与活锁 7.2.6 死锁与活锁 2活锁与死锁的解除 （1）活锁的解除 采用“先来先执行”、 “先到先服务” 策略，也就是 采取简单的排队方式。 当多事务请求封锁同一数据时，封锁子系统按照 先后次序对这些事务请求排队；该数据上锁一旦 释放，首先批准申请队列中第一个事务获得锁。 7.2.6 死锁与活锁 （2）死锁的解除 预防法： 即预先采用一定操作模式避免 死锁的出现 顺序申请法：将封锁对象按顺序编号，事 务在申请封锁时按顺序编号（从小到大或 者反之）申请，避免死锁发生。 7.2.6 死锁与活锁 （2）死锁的解除 一次申请法： 事务在执行开始时将它需要 的所有锁一次申请完成，并在操作完成后 一次性归还所有的锁。 7.2.6 死锁与活锁 （2）死锁的解除 解除法：允许产生死锁，在死锁产生后通 过一定手段予以解除。 定时法：对每个锁设置一个时限，当事务 等待此锁超过时限后即认为已经产生死锁 ，此时调用解锁程序，以解除死锁。 7.2.6 死锁与活锁 （2）死锁的解除 等待图法：事务等待图是一种特殊的有向 图G，其中G的顶点表示正在运行的事务， G的边表示事务等待的情形。事务等待图实 例如图7-25所示。其中，如果事务T2等待 事务T1就画出由T2到T1的有向边等。建立 事务等待图后，检测死锁就转化为判断G中 是存在回路问题。 7.2.6 死锁与活锁 并发控制子系统周期性检测事务等待图， 检验方法可以基于“数据结构与算法”中的拓 扑排序原理，即如果G中顶点能够实现拓扑 排序，则其中没有回路，即无死锁存在， 否则事务等待图中就存在死锁。 7.2.6 死锁与活锁 7.2.6 死锁与活锁 发现死锁后，通常选择一个处理死锁代价 最小的事务即“年轻”（完成事务工作量少） 事务予以撤销，释放该事务持有的所有锁 ，使“年老”(完成事务工作量大)的事务先行 执行，待这些事务执行完成并释放封锁后 ，撤销的“年轻”事务再继续执行。在图7-25 中，可根据情况先行撤销T1、T2或T3中一 个可使得其余事务继续执行。 7.2.6 死锁与活锁 在DBMS运行时，死锁本身相当棘手，人们 自然不希望死锁发生。但如果采取严格措 施，杜绝死锁发生，让事务任意并发，就 有可能破坏数据库中数据，或者使得用户 读取错误数据。从这个意义上讲，死锁的 发生也有防止错误发生的作用。 7.2.6 死锁与活锁 1事务级故障 事务级故障也称为小型故障，其基本特征 是故障产生的影响范围在一个事务之内。 7.3 数据库故障恢复 7.3.1 数据库故障分类 2系统级故障 （1）系统故障 （2）外部故障 7.3.1 数据库故障分类 3介质级故障 （1）磁盘故障 （2）计算机病毒 （3）黑客入侵 7.3.1 数据库故障分类 1基本原理 确定数据库是否可以恢复的依据就是其包含的每 一条信息是否都可以利用冗余的、存储在其它地 方的信息进行重构。基本方法是：数据转储和登 记日志文件。 实行数据转储：定时对数据库进行备份，其作用 是为恢复提供数据基础。 建立日志文件：记录事务对数据库的更新操作， 其作用是将数据库尽量恢复到最近状态。 7.3.2 数据库故障恢复技术 2数据转储 数据转储是定期将数据库中的内容复制到 另一个存储设备中去，这些存储的拷贝称 为后援副本或者后备副本。一旦系统发生 介质故障，数据库遭到破坏，就通过后备 文件的装入，将数据库恢复起来。 7.3.2 数据库故障恢复技术 （1）从转储运行状态看，可分为静态和动态转储 。 静态转储：指的是转储过程中无事务运行，此时 不允许对数据执行任何操作（包括存取与修改操 作），转储事务与应用事务不可并发执行。静态 转储得到的必然是具有数据一致性的副本。 动态转储：即转储过程中可以有事务并发运行， 允许对数据库进行操作，转储事务与应用程序可 以并发执行。 7.3.2 数据库故障恢复技术 （2）从转储进行方式来看，可以分为海量 与增量转储。 海量转储：每次转储数据库全部数据， 增量转储：每次转储数据库中自上次转储 以来产生变化的那些数据。 7.3.2 数据库故障恢复技术 3日志文件 （1）日志文件 日志（Logging）是系统为数据恢复采取的另一 种数据冗余措施。日志作为一个文件，用以记录 事务对数据库的每一次插入、删除和修改等更新 操作，同时记录更新前后的值，使得以后在恢复 时“有案可查”、“有据可依”。 7.3.2 数据库故障恢复技术 （2）日志文件类型 以记录为单位的日志格式称为日志记录（Log Record ）。日志记录中的基本内容有： 每个事务的开始标志（BEGIN TRANSACTION） 每个事务的结束标志（COMMIT 或 ROLLBACK） 每个事务的所有更新操作（插入、删除和修改） 7.3.2 数据库故障恢复技术 以数据块为单位的日志文件，只要某个 数据块中存在数据更新，就需要将整个数 据块更新前和更新后的内容放入到日志文 件中。 7.3.2 数据库故障恢复技术 （3）运行记录优先原则 日志以事务为单位，按执行的时间次序进行记录 ，同时遵循“运行记录优先”原则。在恢复处理过 程中，将对数据进行的修改写到数据库中和将表 示该修改的运行记录写到日志当中是两个不同的 操作，这样就有一个“先记录后执行修改”还是“先 执行修改再记录”的次序问题。如果在这两个操作 之间出现故障，先写入的一个可能保留下来，另 一个就可能丢失日志。如果保留下来的是数据库 的修改，而在运行记录中没有记录下这个修改， 以后就无法撤销这个修改。由此看来，为了安全 ，运行记录应该