吉林大学 数据库系统原理 期末复习 第七部分 事务

7. 1 事务概念

事务是访问并可能更新各种数据项的一个执行单元。我们要求数据库系统维护事务的以下性质

• 原子性：事务的所有操作在数据库中要么全部正确反映出来，要么完全不反映
• 一致性：隔离执行时保持数据库保持数据库的一致性。
• 隔离性：尽管多个事务可能并发执行，但系统保证，对于任何一对事务Ti和Tj，在Ti看来，Tj或者在Ti开始之前已经完成执行，或者在Ti完成之后执行。因此，每个事务都感觉不到系统中有其他事务在并发地执行
• 持久性： 一个事务成功完成后，它对数据库的改变是永久的，即使出现系统故障。

这些性质通常被称为ACID特性。

7.2 事务原子性和持久性

关于事务的一些概念

• 中止：事务并非总能成功地执行完成
• 回滚：中止事务造成的变更被撤销
• 日志：每个事务对数据库的修改会先记录到日志中。记录执行修改的事务标识符，修改的数据项标识符，数据项旧值，数据项新值。之后再修改。维护日志提供了重做修改以及撤销修改以保证原子性，持久性可能。
• 提交：成功完成执行的事务
• 补偿事务：撤销已提交事务所造成影响的唯一方法是执行的事务

事务的状态：

• 活动的： 初始状态，事务执行时出处于这个状态
• 部分提交的：最后一条语句执行后，
• 失败的：发先正常的执行不能继续时
• 中止的：事务回滚且数据库已恢复到事务开始执行前的状态。
• 提交的：成功完成后

进入中止状态后，系统有两个选择：

• 重启事务：但仅当事务中止是硬件错误，而不是事务的逻辑错误所产生的软件错误。重启的事务被看成一个新事务
• 杀死事务：通常是由于书屋的内部逻辑造成的错误

7.3 事务隔离性

事务处理系统允许多个事务并发地执行，并发处理的好处主要是两点：

• 提高吞吐量和资源利用率：吞吐量——即给定时间内执行的事务数增加。相应地，处理器与磁盘利用率也提高。
  即处理器与磁盘空闲或者没有做有用的工作的时间较少。
• 减少等待时间：并发执行可以减少执行事务时不可预测的延迟。也可减少平均响应时间：即一个事务从提交到完成所需的平均时间。

数据库系统必须控制事务之间的交互，以防止它们破坏数据库的一致性。系统称为并发控制机构。

调度结果等价于串行调度的调度称为可串行化调度。

7.4 可串行化

在调度中通常只显示read 与write指令

冲突指令

• A读取区间K，B写取区间K
• B读取区间K，A写取区间K
• A写取区间K，B写取区间K

非冲突指令

• Ａ读区间Ｋ，Ｂ读区间Ｋ
• Ａ读区间Ｋ1，Ｂ读区间Ｋ2

如果调度S可以经过一系列的非冲突指令交换转换成S’，我们称S与S’是冲突等价的。

冲突可串行化：若一个调度S与一个串行调度冲突等价，则称S是冲突可串行化

如果图中没有环的则称为可以冲突串行化。

视图可串行化

• 对于每个数据项Q，若事务Ti在调度S中读取了Q的初始值，那么Ti在调度S’中也必须读取Q的初始值
• 对于每个数据项Q，若事务Ti在调度S中执行了read(Q)，并且读取的值是由Tj产生的，那么Ti在调度S’中读取的Q值也必须是由Tj产生的
• 对于每个数据项Q，若在调度S中有事务执行了最后的write(Q)，则在调度S’中该事务也必须执行最后的write(Q)

7.4 事务隔离性和原子性

7.4.1 可恢复调度

一个可恢复调度应满足：对每对事务A、B，若A读取了由B所写的数据项，则要保证B先提交，A后提交。

7.4.2 无级联调度

无级联调度：对于每队事务A和B，如果A读取了B之前写的数据，B必须在读操作之前提交。每一个无级联调度也都是可恢复调度

7.5 事务隔离级别

隔离性级别越高越能保证一致性，但响应、性能上也要相应牺牲

• 可串行化：通常保证可串行化调度
• 可重复读：只允许读取已经提交的数据，而且一个事务两次读取一个事务期间，其他事务不得更新该数据
• 已提交读：读取的数据必须是已经提交的，但不要求可重复读。一个事务两次读取同一数据项期间，其他事务可更新该数据。
• 未提交读：允许读取尚未提交的数据。

上述所有隔离性级别都不允许脏写，即如果一个数据项已经被另外一个尚未提交或中止的事务写入，则不允许对该数据项执行写操作。

7.6 基于锁的协议

确保隔离性的方法之一是要求对数据项以互斥方式进行访问。实现该需求最常用的方法是只允许事务访问当前该事务持有锁（lock）的数据项。

7.6.1 锁

• 共享的： 如果事务T获得了数据项Q上的共享型锁（记为S），则 T可读但不能写Q。
• 排他的：如果事务T获得了数据项Q上的排他型锁（记为X），则 T既可读又可写Q。

要求每个事务都要根据自己将对数据项Q进行的操作类型申请适当的锁。事务只有在并发控制管理器授予所需锁后才能继续其操作。

这两种锁类型的使用可以让多个事务读取一个数据项但是限制同时只能有一个事务进行写操作。

对于给定的一个锁集合，可在它们上按如下方式定义一个相容的类型。

要访问一个数据项，事务必须首先给该数据项加锁。如果该数据项已经被另一个事务加上不相容的类型的锁，那只好等待。

7.6.2 锁的授予

饿死：指的是当前事务A申请对数据X加写锁，X当前已被事务B加了共享读锁，A等待中持续有一系列对X共享读请求，均被满足，故而A持续等待的现象（事务A可能永远不能取得进展）。

可通过按如下方式授权加锁来避免事务饿死：当事务A申请对数据项X加M型锁时，并发管理器授权加锁的条件是：

• 1.不存在在数据项X上持有与M型锁冲突的锁的其他事务。
• 2.不存在等待对数据项X加锁且先于A申请加锁的事务。

因此，一个加锁请求就不会被其后的加锁申请阻塞。

7.6.3两阶段封锁协议

保证可串行性的一个协议是两阶段封锁协议。该协议要求每个事务分两个阶段提出加锁和解锁申请：

• 增长阶段：可获得锁，不可释放锁。
• 缩减阶段：可释放锁，不可获得锁。

7.6.4基于图的协议

前提：需要知道所有需要访问的数据项及其访问顺序。

依据参与并发事务集合产生的数据项集，数据项顺序要求构造一个图，可以视为有向无环图，称为数据库图。

在树形协议中，可用的加锁指令只有 lock-X 。

单个事务对一个数据项最多能加一次锁，并且遵从以下规则：

• 首次加锁，可直接对数据项加锁。
• 非首次，加锁数据项前，需依次先对数据项各个祖先加锁。
• 解锁，随时可以。
• 数据项在同一事务中只可被加锁一次（即数据项被A加锁并解锁后，A不能再对该数据项加锁）。

7.6.5死锁处理

存在一个事务环路，环路中每个事务因为下一个事务持有的资源而阻塞（每个事务本身持有造成上一事务阻塞的资源）。

死锁产生时，解决是选择一个或若干事务，让其回滚到获得某个锁时刻之前，它在该点得到一个锁，而释放该锁就可以解决死锁。

处理死锁问题的两类方法：

• 死锁预防协议：保证系统永不进入死锁状态。
• 死锁检测和死锁恢复机制：允许进入死锁，通过死锁检测检测死锁，通过死锁恢复进行恢复。

死锁预防
死锁预防有两种方法：

第一：对加锁请求进行排序或要求同时获得所有锁来保证不会发生循环等待。

最简单的机制是：事务开始前一次封锁所有涉及数据项。此外，要么一次全部封锁要么全不封锁。

缺点：

• 在事务开始前通常很难预知哪些数据项需要封锁。
• 数据项使用率可能很低，因为许多数据项可能封锁很长时间却用不到。

另一种机制：对数据项指定顺序，同时要求事务需按规定顺序加锁数据项。
该方法的一个变种是使用数据项与两阶段封锁关联的全序。

第二：每当有可能死锁时，进行事务回滚。

使用抢占和事务回滚。
事务B持有A的锁，可能将B回滚让其释放锁，来满足A。
给每个事务赋一个唯一的时间戳，系统用时间戳来决定事务应等待还是回滚。
利用时间戳的两种不同的死锁预防机制：
１．wait-die——非抢占。
事物A申请的数据项被事务B持有。
若Ａ的时间戳小于B，则A等待；若A的时间戳大于B，则A回滚。
２．wound-wait——抢占（时间戳越小优先级越高）。
事务A申请的数据项被事务B持有。
若A的时间戳大于B的时间戳，则A等待；若A的时间戳小于B的时间戳，B回滚。

另一种处理死锁的简单方法基于锁超时。
超时时，事务回滚。

超时时间合理确定是一个问题。一般而言很难确定一个事务超时之前应等待多长时间。如已发生死锁，等待时间太长导致不必要的延迟。如果等待时间太短，即便没有死锁，也可能引起事务回滚，造成资源浪费。
该机制也可能会产生饿死。

死锁检测与恢复
如果系统没有采用能保证不产生死锁的协议，那么系统必须采用检测与恢复机制。

检查系统状态的算法周期性地激活，判断有无死锁发生。如果发生死锁，则系统必须试着从死锁中恢复。

系统必须：

• 维护当前将数据项分配给事务的有关信息，尚未解决数据项的请求信息。
• 提供一个使用这些信息判断系统是否进入死锁状态的算法。
• 当检测算法检测存在死锁时，从死锁恢复。

从死锁中恢复

当一个检测算法判定存在死锁时，系统必须从死锁中恢复。解除死锁最通常的做法是回滚一个或多个事务。需采取的动作有三个：

1.选择牺牲者

• 事务已经计算了多久，离完成将将计算多久。
• 事务已经使用了多少数据项，离完成还需使用多少数据项。
• 回滚时将牵涉多少事务。

2.回滚

• 彻底回滚：中止该事务，然后重新开始。
• 部分回滚：要求系统维护所有正在运行事务的额外状态信息。

3.饿死
同一事务总是被选为牺牲者时的现象。
可在选择时考虑到事务的已被回滚次数。