第十五章 其它事务处理技术

前两章分别介绍了并发控制技术和系统恢复技术，本章介绍其它三种事务处理技术：死锁处理；高性能事务处理系统和长事务处理技术。死锁处理可以作为并发控制等技术的补充。高性能事务处理技术主要讨论在发展硬件和提高并发性之外的高速事务处理技术。长事务主要是指由于包含交互性应用等人工干预环节而造成运行时间过长的事务。在前述并发控制技术中起着关键作用的可串行性概念并不适用于长事务处理。这里仅介绍一些基本的方法。

第一节 死锁处理第二节 高性能事务处理系统第三节 长事务处理技术

O

第一节 死锁处理在数据库系统运行期间，若事务集合 T={T0 ,T1 ,…,Tn} 的状态为 T0 等待 T1 对某数据项解锁； T1 等待 T2 对某数据项解锁； ……………… ； Tn 等待 T0 对某数据项解锁。

则称系统处于死锁状态，称 T 为死锁事务集合。解决死锁的方法主要有两类： 1 使用预防死锁协议使死锁状态不会出现。协议的目的是破 坏产生死锁的条件。 2 建立对死锁的检测和恢复机制，使系统摆脱死锁状态。检 测方法主要有简单的超时法和准确的等待图法。摆脱死锁 的基本原理是撤销某些陷入死锁的事务，释放其获得的锁 和其它资源。当死锁的发生概率较高时，用第 1 类方法效率较高，否则使用第2 类方法较好。下边分别介绍这两类方法。

O1

接下页

壹 预防死锁协议避免系统陷入死锁状态有多种方法。其中三种主要的方法是：一次封锁：事务自始至终锁住全部有关的数据项。这种方法有 效地防止死锁的产生，但以牺牲并发性为代价。顺序封锁：定义数据项的部分序。事务按部分序对数据项加锁 . 树协议就是一例。缺点是部分序的维护复杂。时间印技术：对访问同一数据项的两个事务，比较其时间印， 决定是等待还是撤消。重启事务保持时间印不变。

O11

接下页下边是两个使用时间印 ( 简记为 TS) 的预防死锁协议1 ‘ 等待或死亡’协议 前后两事务访问相同数据项，若后事务的 TS 较小， 则等待前事务解锁，否则，后事务被撤消。重启事务保持 TS 。2 ‘ 等待或伤害’协议 前后两事务访问相同数据项，若后事务 TS 较大， 则等待前事务解锁，否则，前事务被撤消。重启事务保持 TS 。撤销事务总是 TS 较大者。新事务的 TS 较大，故易被撤销。由于在线事务的 TS 总体递增，重启事务的 TS 保持其值而变得相对较小，故事务至多经数次撤销重启总能执行。不发生事务间互相等待的现象。

二 . 死锁检测和恢复技术这种技术允许死锁出现，但须建立对死锁的检测和恢复机制。[ 死锁检测 ] 最简单的检测方法是超时法：若事务等待超过规定的 时间，则认为死锁已出现。此方法可能误判。较准确的是事 务等待图方法。事务等待图是一个有向图 G(V,E) 。点集 V 表 示运行中的事务集，有向边 E(V1,V2) 表示事务 V1 等待事务 V2

释放所需的数据项。显然，系统出现死锁的充要条件是事务 等待图有环。环中的点构成了死锁事务集合。可用图论的回 路算法检测图中是否有环。系统运行时 DBMS周期性地检测 事务等待图。检测周期的长短取决于死锁频繁出现的程度以 及陷入死锁状态的事务个数。[ 死锁恢复 ] 主要的方法是撤消某些死锁事务并消去图中的环。撤消事务的选择：最多回路交叉处事务和最小撤消代价事务。 影响撤销代价的因素是：已完成和未完成的计算量； 已使用和未使用的数据项；同时撤销的事务数等。撤消事务的方法：放弃该事务， undo 其所有操作，重新启动。无限等待问题： 若采用基于代价的选择，为避免某些事务总 被选上导致无限等待，可把已撤销次数包含在代价中。

O12

第二节 高性能事务处理系统为了实现高性能的事务处理系统，除了引入高性能硬件和充分发挥系统的并行性外，还需要其它技术，下边介绍两个方面：壹 主存数据库 数据库系统的性能受到磁盘读写速度的限制。增加主存缓冲区 的大小可以减少这种限制。若大容量主存储器足以容纳整个数 据库，则应用系统的性能就能得到最大的发挥。虽然大型数据 库无法全部放入主存，但大部分数据放入主存同样可以加快事 务处理的速度。但注意增大缓冲区同时也增加管理的复杂性， 例如检测点的操作、故障恢复后缓冲区数据的重建以及日志记 录向永恒存储器的输出，都不同程度地增加时间上的开销。二 事务的成批提交技术 每个事务 T 的提交都需要对永恒存储器作读和写两次操作： 第一次把与 T 有关的记录读到主存；第二次把 (T,commits)写入 永恒。传输的数据中只有少部分是更新数据， I/O 时间的利用 率低。事务的成批提交技术是指多个事务完成后才集中提交。 可以节省访问永恒存储器的次数，也可以提高传送有用数据的 比例。缺点是延迟事务提交。高性能系统可以接受这种延迟。

O2

第三节 长事务处理技术前述的事务一般假定运行时间较短和非交互式操作。并发控制和数据库恢复技术能有效处理这些事务。但当这些技术应用到交互性的长事务，将引起严重的问题。长事务特点如下： 1 人工干预必然造成运行时间长 2 用户和其它事务在长事务结束前被迫使用未提交数据； 3 用户希望仅撤消长事务的某个子任务，尽量避免重复工作； 4 故障后用户希望恢复到最近状态，保留更多的人工工作； 5 响应时间是交互式事务系统更重要的性能指标。一 . 可串行性概念不适合于长事务处理前述的并发控制协议只允许可串行调度，不适合处理长事务。两段锁协议：当事务等待长事务解锁时，长等待增加死锁机会 ,数据图协议：因解锁后不得再加锁，故长事务将长时间不解锁 , 延长系统响应的时间。时间印协议：若撤消长事务，将失去大量工作，包括用户手工 操作的结果。这些协议还可能引起事务的嵌套撤销，对长事务更为不利。因此对长事务的并发控制不应该依赖可串行性的概念。

O3

接下页

二 嵌套事务技术把长事务 T构造成具有部分序 P 的一组子事务 {Ti} 的集合，其中某些子事务可以并发运行。当系统发生故障时，数据库恢复机构根据需要可以撤消部分子事务 Ti ，而不必撤消长事务 T 。 T 可重新启动运行这些被撤消的子事务 Ti 或简单地废弃之。 Ti 的提交只是对 T 提交， Ti 对数据库的影响并不永久地写入数据库。只有 T 的提交才综合地体现出各子事务对数据库的影响。长事务 T 的执行遵循部分序 P.下图表示了由四个具有部分序的子事务组成的长事务。子事务11a 和 11b 可并发运行。由于系统发生某种故障，恢复机构仅撤销子事务 111 。由于没有撤销其它子事务，因而在系统恢复中避免了大量重复性的操作，特别是人工操作。

O31

子事务 1 子事务 111子事务 11a

可并发运行子事务 11b

允许长事务有多级的嵌套结构，即子事务由若干个具有部分序的子事务组成。最低级别的子事务包含标准操作 read 和 write.

接下页

T1 T2read(a);a:=a-1;write(a); read(b); b:=b-2; write(b);read(b);b:=b+1;write(b); read(a); a:=a+2; write(a); 故障 ;T2 的补救算法：a:=a+2;b:=b-2;

三 补救事务技术对于非交互方式的短事务，为了保证事务的原子性，采用了 undo操作撤消失败事务对数据库的影响。这种处理方法并不适合于长事务。原因是未提交数据的扩散，会造成大量的事务嵌套撤销。补救事务技术并不撤销异常结束事务对数据库的修改，而是采取特殊行动来补救所引起的问题。这种特殊行动通常是为每一个事务写出其专用的补救算法。如右图，事务 T1 和 T2 的调度并不满足冲突可串行性，但结果是正确的。若 T2 在结束前发生故障，按照嵌套撤销规则，两个事务都必须作 undo 处理。若采用补救事务技术，每个事务都必须预先提供补救算法，其中 T2 的补救算法是 a:=a+2;b:=b-2. 由于此例的故障出现在 T2 ，所以仅运行 T2 对应的补救事务就可以了。恢复行动不必考虑 T1

O32

接下页

肆 实时数据库系统实时数据库系统 (Real Time Database System,RTDBS) 是指被用于实时控制领域的数据库系统。例如电力调度、交通控制、证券交易等管理系统使用的数据库系统就属于 RTDBS 。 RTDBS 事务的运行往往具有时间限制，要求在指定时间内完成。这种应用系统既需要数据库支持数据共享，维护其数据的一致性，又需要实时处理支持事务的定时限制。故系统的实现有很高的难度。若并发控制协议决定事务 T 等待解锁，系统有时会强制另一事务S 解锁使 T 得以按时完成。但这样处理必须倍加小心，因为强制S 解锁导致 S 的撤销和重启，可能使 S未必能在指定时间内完成。系统决定让 T 等待还是决定撤销其它事务，很难建立一个准确的判断条件。原因是事务的执行复杂性与系统的即时状态密切相关。例如，当 T所需要的数据项 Q 已经读入主存缓冲区，则 T读Q 的执行时间很短，但若 Q 不在主存缓冲区，则 T 就必须从磁盘读取 Q ，执行时间将增加若干个数量级。RTDB 并非是数据库和实时系统两者的简单结合，它需要对一系列的概念、理论、技术、方法和机制进行研究开发。国内外均已出现成功的实验系统。

O33