事务没有达到预期的终点(COMMIT或者显式的ROLLBACK)，数据库可能处于不正确状态。

事务故障的恢复：事务撤消（UNDO）

强行回滚（ROLLBACK）该事务
撤销该事务已经作出的任何对数据库的修改，使得该事务象根本没有启动一样

系统故障（UNDO & REDO）

称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动。

常见的原因有：
特定类型的硬件错误（如CPU故障）
操作系统故障

数据库管理系统代码错误
系统断电

发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，造成数据库可能处于不正确状态。

恢复策略：系统重新启动时，恢复程序让所有非正常终止的事务回滚，强行撤消（UNDO）所有未完成事务

发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或全部丢失

恢复策略：系统重新启动时，恢复程序需要重做（REDO）所有已提交的事务

介质故障

介质故障破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务

计算机病毒

2.4恢复的技术实现

1.建立冗余数据（数据转储 & 登记日志文件）
2.利用冗余数据进行数据库恢复

数据转储

转储是指数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程

备用的数据文本称为后备副本(backup)或后援副本

重装后备副本只能将数据库恢复到转储时的状态
要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务

 静态转储与动态转储

静态转储  在系统中无运行事务时进行的转储操作

动态转储 转储操作与用户事务并发进行

海量转储与增量转储

海量转储: 每次转储全部数据库

增量转储: 只转储上次转储后更新过的数据

从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

登记日志文件

日志文件(log file)是用来记录事务对数据库的更新操作的文件

日志文件的作用：
进行事务故障恢复
进行系统故障恢复
协助后备副本进行介质故障恢复

常用的格式有以记录为单位的日志文件 和 以数据块为单位的日志文件

以记录为单位的日志文件包括：
各个事务的开始标记(BEGIN TRANSACTION)
各个事务的结束标记(COMMIT或ROLLBACK)
各个事务的所有更新操作

以记录为单位的日志文件，每条日志记录的内容
事务标识（标明是哪个事务）
操作类型（插入、删除或修改）
操作对象（记录ID、Block NO.）
更新前数据的旧值（对插入操作而言，此项为空值）
更新后数据的新值（对删除操作而言, 此项为空值）

以数据块为单位的日志文件，每条日志记录的内容
事务标识
被更新的数据块

必须先写日志文件，后写数据库

2.5恢复策略

事务故障恢复（UNDO）

事务故障：事务在运行至正常终止点前被终止
恢复方法：由恢复子系统利用日志文件撤消（UNDO）此事务已对数据库进行的修改

事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预步骤：
1.反向扫描文件日志
2.对该事务的更新操作执行逆操作
3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理
4. 直至读到此事务的开始标记

系统故障恢复

系统故障造成数据库不一致状态的原因
未完成事务对数据库的更新可能已写入数据库——UNDO
已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库——REDO

系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

步骤：
1.正向扫描日志文件得到重做(REDO) 队列 和 撤销 (UNDO)队列
2.对撤销(UNDO)队列事务进行撤销(UNDO)处理——参考上面
3.对重做(REDO)队列事务进行重做(REDO)处理

介质故障恢复

1.重装数据库
2.重做已经完成的事务

步骤：
1.装入最新后备数据库副本（动态的需要装入日志文件）
2.装入有关的日志文件的副本（转储结束时刻的日志文件副本），重做已经完成的事务

介质故障的恢复需要数据库管理员介入

具有检查点的恢复技术

检查点恢复技术是为了解决搜索整个日志和重做出理耗费大量的事件

具有检查点的恢复技术：
在日志文件中增加检查点记录
增加重新开始文件
恢复子系统在登录日志文件期间动态地维护日志

检查点记录的内容：
建立检查点时刻所有正在执行的事务清单
这些事务最近一个日志记录的地址

重新开始文件的内容：
记录各个检查点记录在日志文件中的地址

步骤：
1.将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
2.在日志文件中写入一个检查点记录
3.将当前数据缓冲区的所有数据记录写入磁盘的数据库中
4.把检查点记录在日志文件中的地址写入一个重新开始文件

检查点的保存可以是定期的也可以是不定期的

数据库镜像

数据库管理系统自动把整个数据库或其中的关键数据复制到另一个磁盘上

发生故障时使用镜像

在实际应用中用户往往只选择对关键数据和日志文件镜像

 三、并发控制

并发控制的基本概述

事务是并发控制的基本单位

并发控制的任务：
对并发操作进行正确调度
保证事务的隔离性
保证数据库的一致性

种类

• 事务串行执行
• 交叉并发方式
• 同时并发方式

并发操作带来的数据不一致性：
1.丢失修改（Lost Update）
2.不可重复读（Non-repeatable Read）
3.读“脏”数据（Dirty Read）

数据不一致性：由于并发操作破坏了事务的隔离性
并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其他事务的干扰，从而避免造成数据的不一致性

封锁

封锁就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁，加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。

基本封锁类型：排他锁（X锁） & 共享锁（S锁）

排他锁

排它锁又称为写锁
若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁
保证其他事务在T释放A上的锁之前不能再读取和修改A

共享锁

共享锁又称为读锁
若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁
保证其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改

封锁协议

在运用X锁和S锁对数据对象加锁时，需要约定一些规则，这些规则为封锁协议（Locking Protocol）。

一级封锁协议——不可重复读 & 读脏数据

事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。

一级封锁协议可防止丢失修改，并保证事务T是可恢复的。
在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读“脏”数据。

二级封锁协议——丢失修改 & 读脏数据

一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。

在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。

三级封锁协议——丢失修改 & 读脏数据 & 不可重复读

一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。

活锁和死锁

活锁

避免活锁：采用先来先服务的策略
当多个事务请求封锁同一数据对象时
按请求封锁的先后次序对这些事务排队
该数据对象上的锁一旦释放，首先批准申请队列中第一个事务获得锁

死锁

死锁的预防

预防死锁的发生就是要破坏产生死锁的条件

一次封锁法

要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行

会降低系统并发度

顺序封锁法

顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。

会导致维护成本很高，并且往往难以实现

死锁的诊断与解除