西华师范大学计算机学院
第七章 数据库恢复技术
第三篇 系统篇
? 数据库系统中的数据是由 DBMS统一管理和控制的,
为了适应数据共享的环境, DBMS必须提供数据保
护能力, 以保证数据库中数据的安全可靠和正确有
效 。
? 数据保护
– 安全性
– 完整性
– 并发控制
– 数据库恢复：在某些错误与失败导致当前数据库
状态 （ 数据库内容 ） 不正确时, 恢复数据库到一
个确知的正确数据库状态 。
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.1 事务的基本概念
一、什么是事务
二、如何定义事务
三、事务的特性
一、什么是事务
? 事务 (Transaction)是用户定义的一个数据库操
作序列，这些操作要么全做，要么全不做，是
一个不可分割的工作单位
? 事务和程序是两个概念
– 在关系数据库中，一个事务可以是一条 SQL语句，
一组 SQL语句或整个程序
– 一个应用程序通常包含多个事务
? 事务是恢复和并发控制的基本单位
二、如何定义事务
? 显式定义方式
BEGIN TRANSACTION BEGIN TRANSACTION
SQL 语句 1 SQL 语句 1
SQL 语句 2 SQL 语句 2
。。。。。 。。。。。
COMMIT ROLLBACK
如下面的示例在图书的截止当前销售额超过 $8,000 时，增加支付
给作者的预付款。
BEGIN TRANSACTION
USE pubs
UPDATE titles
SET advance = advance * 1.25
WHERE ytd_sales > 8000
COMMIT
二、如何定义事务
? 隐式方式
当用户没有显式地定义事务时，
DBMS按缺省规定自动划分事务
事务结束
COMMIT
事务正常结束
提交 事务的所有操作（ 读 +更新 ）
事务中所有对数据库的更新 永久 生效
ROLLBACK
事务异常终止
– 事务运行的过程中发生了故障，不能继续执行
回滚事务的所有 更新 操作
– 事务滚回到 开始 时的状态
三、事务的特性 (ACID特性 )
事务的 ACID特性：
? 原子性（ Atomicity）
? 一致性（ Consistency）
? 隔离性（ Isolation）
? 持续性（ Durability ）
1,原子性
? 事务是数据库的逻辑工作单位
– 事务中包括的诸操作要么都做，要么都不做
2,一致性
事务执行的结果必须是使数据库从一个
一致性状态变到另一个一致性状态
一致性状态,
数据库中只包含成功事务提交的结果
不一致状态,
数据库中包含失败事务的结果
一 致性与原子性
银行转帐：从帐号 A中取出一万元，存入帐号 B。
– 定义一个事务，该事务包括两个操作
– 这两个操作要么全做，要么全不做
? 全做或者全不做，数据库都处于一致性状态。
? 如果只做一个操作，数据库就处于不一致性状态 。
B=B+1
A=A-1
BA
3,隔离性
对并发执行而言
一个事务的执行不能被其他事务干扰
? 一个事务内部的操作及使用的数据对其他并发
事务是隔离的
? 并发执行的各个事务之间不能互相干扰
T1的修改被 T2覆盖了！
读 A=16
A←A -3
写回 A=13
① 读 A=16
②
③ A←A -1
写回 A=15
④
T2T1
4,持续性
? 持续性也称永久性（ Permanence）
– 一个事务一旦提交，它对数据库中数据的改
变就应该是永久性的。
– 接下来的其他操作或故障不应该对其执行结
果有任何影响。
事务的特性
? 保证事务 ACID特性是事务处理的任务
? 破坏事务 ACID特性的因素
– 多个事务并行运行时，不同事务的操作交叉执行
– 事务在运行过程中被强行停止
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.2 数据库恢复概述
? 故障是不可避免的
– 计算机硬件故障
– 系统软件和应用软件的错误
– 操作员的失误
– 恶意的破坏
? 故障的影响
– 运行事务非正常中断
– 破坏数据库
数据库恢复概述（续）
? 数据库管理系统对故障的对策
– DBMS提供恢复子系统
– 保证故障发生后，能把数据库中的数据从错
误状态恢复到某种逻辑一致的状态
– 保证事务 ACID
? 恢复技术是衡量系统优劣的重要指标
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
一、事务故障
? 什么是事务故障
– 某个事务在运行过程中由于种种原因未运行至正常
终止点就夭折了
? 事务故障的常见原因
– 输入数据有误
– 运算溢出
– 违反了某些完整性限制
– 某些应用程序出错
– 并行事务发生死锁
– 。。。。
事务故障的恢复
? 发生事务故障时，夭折的事务可能已把
对数据库的部分修改写回磁盘
? 事务故障的恢复,撤消事务（ UNDO）
? 强行回滚（ ROLLBACK）该事务
? 清除该事务对数据库的所有修改，使得
这个事务象根本没有启动过一样
二、系统故障
? 什么是系统故障
– 整个系统的正常运行突然被破坏
– 所有正在运行的事务都非正常终止
– 内存中数据库缓冲区的信息全部丢失
– 数据库不被破坏，但可能处于不正确的状态
系统故障的常见原因
? 操作系统或 DBMS代码错误
? 操作员操作失误
? 特定类型的硬件错误（如 CPU故障）
? 突然停电
系统故障的恢复
? 清除尚未完成的事务对数据库的所有修改
– 系统 重新启动时,恢复程序要强行撤消
（ UNDO）所有未完成事务
? 将缓冲区中已完成事务提交的结果写入数据库
– 系统 重新启动时,恢复程序需要重做
（ REDO）所有已提交的事务
7.3 故障的种类
? 事务故障
? 系统故障
? 介质故障
三、介质故障
? 硬件故障使数据库本身遭到破坏，存储
数据库数据的介质不能读写。这是一种
最严重的失败。
介质故障的常见原因
? 硬件故障
– 磁盘损坏
– 磁头碰撞
– 操作系统的某种潜在错误
– 瞬时强磁场干扰
介质故障的恢复
? 装入 数据库发生介质故障前某个时刻的
数据 副本
? 重做自此时始的所有 成功事务,将这些
事务已提交的结果重新记入数据库
恢复操作的基本原理
? 恢复操作的基本原理,冗余
– 利用 存储在系统其它地方的 冗余数据 来 重建
数据库中已被破坏或不正确的那部分数据
? 恢复的实现技术：复杂
– 一个大型数据库产品，恢复子系统的代码要
占全部代码的 10%以上
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.4 恢复的实现技术
恢复机制涉及的关键问题
1,如何建立冗余数据
? 数据转储（ backup）：数据库的复本
? 登录日志文件（ logging）：日志记录引起
数据库的状态变化的各种修改
2,如何利用这些冗余数据实施数据库恢复
7.4.1 数据转储
一、什么是转储
二、转储的用途
三、转储方法
一、什么是转储
? 转储是指 DBA将整个数据库复制到磁带或另一
个磁盘上保存起来的过程。
? 这些备用的数据文本称为后备副本或后援副本。
转储
故障发生点
转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本 重新运行事务
恢复 ─┼───────┴ －－－－－－－－－－－ － →
三、转储方法
1．静态转储与动态转储
2．海量转储与增量转储
3．转储方法小结
1．静态转储
? 在系统中无运行事务时进行转储
? 转储开始时数据库处于一致性状态
? 转储期间不允许对数据库的任何存取、
修改活动
? 优点,实现简单
? 缺点,降低了数据库的可用性
– 转储必须等用户事务结束
– 新的事务必须等转储结束
利用静态转储副本进行恢复
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本
恢复 ─┼─────── ┥
动态转储
? 转储操作与用户事务并发进行
? 转储期间允许对数据库进行存取或修改
? 优点
– 不用等待正在运行的用户事务结束
– 不会影响新事务的运行
? 动态转储的缺点
– 不能保证副本中的数据正确有效
动态转储
? 利用动态转储得到的副本进行故障恢复
– 需要把动态转储期间各事务对数据库
的修改活动登记下来，建立日志文件
– 后备副本加上日志文件才能把数据库
恢复到某一时刻的正确状态
利用动态转储副本进行恢复
运行事务 故障发生点
动态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本 利用日志文件恢复
恢复 ━━━━━━╋ ━ ━ ━ ┥
利用动态转储副本进行恢复
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
2．海量转储与增量转储
? 海量转储, 每次转储全部数据库
? 增量转储, 只转储上次转储后更新过的数据（日志数据）
? 海量转储与增量转储比较
– 从恢复角度看，使用海量转储得到的后备副本进行恢
复往往更方便
– 但如果数据库很大，事务处理又十分频繁，则增量转
储方式更实用更有效
3．转储方法小结
? 转储方法分类
转储状态
动态转储 静态转储
转储
方式
海量转储 动态海量转储 静态海量转储
增量转储 动态增量转储 静态增量转储
转储策略
? 应定期进行数据转储，制作后备副本。
? 但转储又是十分耗费时间和资源的，不能频繁进行。
? DBA应该根据数据库使用情况确定适当的转储周期和
转储方法。
例：
– 每天晚上进行动态增量转储
– 每周进行一次动态海量转储
– 每月进行一次静态海量转储
7.4 恢复的实现技术
7.4.1 数据转储
7.4.2 登记日志文件
7.4.2 登记日志文件
一、日志文件的内容
二、日志文件的用途
三、登记日志文件的原则
一、日志文件的内容
1,什么是日志文件
日志文件 (log)是用来记录事务对数据库的
更新操作的文件
2,日志文件的格式
以记录为单位的日志文件
以数据块为单位的日志文件
日志文件的内容（续）
3,日志文件内容
– 各个事务的开始 （ BEGIN TRANSACTION） 标记
– 各个事务的结束 （ COMMIT,ROLLBACK） 标记
– 各个事务的所有更新操作
日志文件中的一个日志记录 (log record)
4,基于记录的日志文件
每条日志记录的内容
– 事务标识
– 操作类型（插入、删除或修改）
– 操作对象（记录 ID）
– 更新前数据的旧值（对插入操作而言，此项为空值）
– 更新后数据的新值（对删除操作而言,此项为空值）
注：数据旧值（ Before Image)和数据新值（ After Image）的粒
度可以不同，可能是整个页面（ Page）也可能是某种较小的
单位（如行或元组）。一般地是一个记录。
5,基于数据块的日志文件
每条日志记录的内容
– 事务标识（标明是那个事务）
– 操作对象（ Block NO）
– 更新前数据所在的整个数据块的值（对插入
操作而言，此项为空值）
– 更新后整个数据块的值（对删除操作而言,
此项为空值）
二、日志文件的用途
1．用途
– 进行事务故障恢复
– 进行系统故障恢复
– 协助后备副本进行介质故障恢复
日志文件的用途（续）
2．与静态转储后备副本配合进行介质故障恢复
– 静态转储的数据已是一致性的数据
– 如果静态转储完成后，仍能定期转储日志文件，
则在出现介质故障重装数据副本后，可以利用
这些日志文件副本对已完成的事务进行重做处
理
– 这样不必重新运行那些已完成的事务程序就可
把数据库恢复到故障前某一时刻的正确状态
日志文件的用途（续）
故障发生点
静态转储 运行事务 ↓
正常运行 ─┼──────┼──────────┼──
Ta Tb Tf
登记日志文件
└─────────── ┴ ──
重装后备副本 利用日志文件恢复事务 继续运行
介质故障恢复 ─────────┴ －－－－－ ─ －－－－－－－ ┴──────
登记日志文件
└──────
日志文件的用途（续）
3,介质故障恢复,LOG FILE + 动态转储后备副本
– 动态转储数据库：同时转储同一时点的日志文件
– 后备副本与该日志文件结合起来才能将数据库恢复
到一致性状态。
– 利用这些日志文件副本进一步恢复事务，避免重新
运行事务程序。
三、登记日志文件的原则
? 为保证数据库是可恢复的，登记日志文件时必
须遵循两条原则
– 登记的次序严格按并行事务执行的时间次序
– 必须先写日志文件，后写数据库
? 写日志文件操作：把表示这个修改的日志记录
写到日志文件
? 写数据库操作：把对数据的修改写到数据库中
登记日志文件的原则（续）
? 为什么要先写日志文件
– 写数据库和写日志文件是两个不同的操作
– 在这两个操作之间可能发生故障
– 如果先写了数据库修改，而在日志文件中没有登记
下这个修改，则以后就无法恢复这个修改了
– 如果先写日志，但没有修改数据库，按日志文件恢
复时只不过是多执行一次不必要的 UNDO操作，并
不会影响数据库的正确性
日志文件特征 --日志超前写
? 与数据库缓冲区一样，数据库日志也保存在内存缓
冲区，称为日志缓冲区（ Log Buffer），以后再被永
久地写入外存。
? 永久地保存日志有两种方法：
– 同步写（ Synchronously）：当日志记录增加（缓冲区）
时，日志从内存立即写到外存（数据库日志）（有时日
志是直接写盘，不经过缓冲区）
– 异步写（ Asynchronously）：同数据缓冲区一样，日志写
到外存（数据库日志）或是周期的写或是缓冲区满后写
日志文件特征 --日志超前写
在数据库恢复中事务日志文件起重要的作用, 一旦日志本身被
破坏, 数据库的部分不能被恢复 。 所以, 无 论 同 步 写
（ Synchronously）, 异步写 （ Asynchronously） 都必须怎遵从一
重要的协议,日志超前写 。
日志文件特征 --日志超前写
? 所谓日志超前写, 简单的讲是向数据库写数据之前必须保证
数据库日志已正确的写入, 它准确的含义如下：
? * 在数据库被修改前 （ 也许是由于一个未提交的事务引
起 ）, 数据旧值 （ Before Image） 必须保证已被成功的存入
数据库日志 。 以便恢复时 Undo操作的完成
? * 当事物提交时 （ 或事务已成功提交 ）, 数据新值
（ After Image） 写入数据库之前, 必须保证已被成功的写入
数据库日志 。 以便恢复时 Redo操作的完成
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.5 恢复策略
7.5.1 事务故障的恢复
7.5.2 系统故障的恢复
7.5.3 介质故障的恢复
7.5.1 事务故障的恢复
? 事务故障：事务在运行至正常终止点前被中止
? 恢复方法
– 由恢复子系统利用日志文件撤消（ UNDO）此事务已对数据
库进行的修改
? 事务故障的恢复由系统自动完成，不需要用户干预
事务故障的恢复步骤
1,反向扫描文件日志（即从最后向前扫描日志文件），
查找该事务的更新操作。
2,对该事务的更新操作执行逆操作。即将日志记录中
“更新前的值”（ Befor Image,BI）写入数据库。
– 插入操作,“更新前的值”为空，则相当于做删除操作
– 删除操作，“更新后的值”为空，则相当于做插入操作
– 若是修改操作，则用 BI 代替 AI（ After Image）
事务故障的恢复步骤
3,继续反向扫描日志文件，查找该事务的其他更新操作，
并做同样处理。
4,如此处理下去，直至读到此事务的开始标记，事务故
障恢复就完成了。
? Undo逻辑
Undo逻辑表述如下：
Undo（ T） = Undo（ Undo（ …… （ T）））
撤消事务的影响本身也是一个事务，执行过程中也可
能失败，失败了也要恢复，这意味着 Undo多次对数
据的更新必须保证好象只做了一次 Undo操作
7.5.2 系统故障的恢复
? 系统故障是指由于各种各样的原因导致系统（ OS,DBMS等）
停止工作，需要重新启动系统
? 系统故障造成数据库不一致状态的原因
– 一些未完成事务对数据库的更新已写入数据库
– 一些已提交事务对数据库的更新还留在缓冲区没来得及写入
数据库
? 恢复方法
– 1,Undo 故障发生时未完成的事务
– 2,Redo 已完成的事务
? 系统故障的恢复由系统在 重新启动时调用恢复过程 自动完成，
不需要用户干预
系统故障的恢复 步骤
1,正向扫描日志文件（即从头扫描日志文件）
– Redo队列, 在故障发生前已经提交的事务
T1,T3,T8…..
– Undo队列,故障发生时尚未完成的事务
T2,T4,T5,T6,T7,T9 …...
系统故障的恢复步骤
2,对 Undo队列事务进行 UNDO处理
反向扫描日志文件，对每个 UNDO事务的更
新操作执行逆操作
T2,T4,T5,T6,T7,T9 ……
3,对 Redo队列事务进行 REDO处理
正向扫描日志文件，对每个 REDO事务重新
执行登记的操作
T1,T3,T8…..
7.5.3 介质故障的恢复
1,重装数据库，
使数据库恢复到一致性状态
2,重做已完成的事务
7.5.3 介质故障的恢复
? 恢复步骤
1,装入最新的后备数据库副本，使数据库恢复到最近一
次转储时的一致性状态。
– 对于静态转储的数据库副本，装入后数据库即处于
一致性状态
– 对于动态转储的数据库副本，还须同时装入转储时
刻的日志文件副本，利用与恢复系统故障相同的方
法（即 REDO+UNDO），才能将数据库恢复到一致
性状态。
利用静态转储副本将数据库恢复到一致性状态
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本
恢复 ━━━━━━┥
利用动态转储副本将数据库恢复到一致性状态
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
介质故障的恢复（续）
2,装入有关的日志文件副本，重做已完成的事务。
– 首先扫描日志文件，找出故障发生时已提交的
事务的标识，将其记入重做队列。
– 然后正向扫描日志文件，对重做队列中的所有
事务进行重做处理。即将日志记录中“更新后
的值”写入数据库。
介质故障的恢复（续）
介质故障的恢复需要 DBA介入
? DBA的工作
– 重装最近转储的数据库副本和有关的各日志
文件副本
– 执行系统提供的恢复命令
? 具体的恢复操作仍由 DBMS完成
介质故障的恢复（续）
存储介质失败的一般恢复过程
* 如有可能, 备份当前的日志文件
* 删除被破坏的用户数据库, 并重建该数据库
* 用一个新的存储介质替代已损坏的存储介质
* 装入 （ Load） 最近的数据库备份
* 如果是使用增量备份, 按备份顺序装入备份的日志
* 装入上述第一步备份的当前日志备份 （ 如果有的话 ）
* 重新启动系统,DBMS用系统失败恢复相同的过程，通过
日志文件对刚装入的备份数据库进行更新，使达到最近的一个
正确的数据库状态
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.6 具有检查点的恢复技术
一、问题的提出
二、检查点技术
三、利用检查点的恢复策略
问题的提出
? 两个问题
– 日志文件记录从系统启动以来数据库的状态变化，保存大
量的事务极其数据库状态变化前后值，一般来说是相当大
的一个文件，特别对更新（插入、删除、修改操作）频繁
的系统更是如此。 搜索整个日志将耗费大量的时间
– 对那些已完成（提交）的事务，由于不能确定是否真正的
永久保存到数据库中，对它们未加区分的进行 重做
（ Redo）,相当于将系统启动以来的所有事务再执行一遍，
显然这是 十分费时 的过程，它是使系统恢复效率低的重要
原因。
解决方案
? 所谓检查点是在某一时刻强迫写 缓冲区数据 到数据库, 即
在该时刻将已完成的事务对数据库的影响永久保存
? 系统提供一检查点命令,Checkpoint,系统周期的发出检
查点命令, 也可由用户执行检查点命令
? 一个检查点主要包含下述信息：
– 在日志文件中增加一个, 检查点记录,, 它包含：
? 该时刻未完成事务列表,Undo表
? Undo表中每个事务在日志文件开始记录地址
– 增加一个启动 （ 重新开始 ） 文件, 它存放检查点记录在日志文件
中的地址
设置检查点
? 发出检查点命令时系统的工作：
? * 将日志缓冲区信息写入日志文件 。 由于完成日
志文件写和数据库的写不是一个操作, 即不是一个
事务 。 在完成检查点操作时应先保证日志文件的完
整的保存
* 将检查点记录写入日志文件
* 将数据库缓冲区信息写入数据库
* 将检查点记录在日志文件的地址写入启动文件
利用检查点的恢复策略
? 当事务 T在一个检查点之前提交
T对数据库所做的修改已写入数据库
? 在进行恢复处理时，没有必要对事务 T执
行 REDO操作
利用检查点的恢复策略（续）
Tc(检查点 ) Tf(系统故障 )
REDO
UNDO
UNDO
REDO
T2
T3
T4
T5
不要 REDOT1
利用检查点的 恢复步骤
1,从重新开始文件中找到最后一个检查点记录在
日志文件中的地址
2 由该地址在日志文件中找到最后一个检查点记
录
利用检查点的恢复策略（续）
2.由该检查点记录得到检查点建立时刻所有正在执
行的事务清单 ACTIVE-LIST
– 建立两个事务队列
? UNDO-LIST
? REDO-LIST
– 把 ACTIVE-LIST暂时放入 UNDO-LIST队列，
REDO队列暂为空。
利用检查点的恢复策略（续）
3.从检查点开始正向扫描日志文件，直到日志文
件结束
– 如有新开始的事务 Ti，把 Ti暂时放入 UNDO-
LIST队列
– 如有提交的事务 Tj，把 Tj从 UNDO-LIST队列
移到 REDO-LIST队列
4.对 UNDO-LIST中的每个事务执行 UNDO操作,
对 REDO-LIST中的每个事务执行 REDO操作
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.7 数据库镜像
? 介质故障是对系统影响最为严重的一种故障，
严重影响数据库的可用性
– 介质故障恢复比较费时
– 为预防介质故障,DBA必须周期性地转储数
据库
? 提高数据库可用性的解决方案
– 数据库镜像（ Mirror）
数据库镜像（续）
? 数据库镜像
– DBMS自动把整个数据库或其中的关键数据
复制到另一个磁盘上
– DBMS自动保证镜像数据与主数据的一致性
(图 7.5a)
数据库镜像的用途
? 出现介质故障时
– DBMS自动利用镜像磁盘数据进行数据库的恢复，
不需要关闭系统和重装数据库副本 (图 7.5b)
? 没有出现故障时
– 可用于并发操作 (图 7.5a)
– 一个用户对数据加排他锁修改数据
– 其他用户可以读镜像数据库上的数据
数据库镜像（续）
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.8 小结
? 如果数据库只包含成功事务提交的结果，就说
数据库处于一致性状态。保证数据一致性是对
数据库的最基本的要求。
? 事务是数据库的逻辑工作单位
– DBMS保证系统中一切事务的原子性、一致
性、隔离性和持续性
小结（续）
? DBMS必须对事务故障、系统故障和介质故障
进行恢复
? 恢复中最经常使用的技术：数据库转储和登记
日志文件
? 恢复的基本原理：利用存储在后备副本、日志
文件和数据库镜像中的冗余数据来重建数据库
小结（续）
? 常用恢复技术
– 事务故障的恢复
? UNDO
– 系统故障的恢复
? UNDO + REDO
– 介质故障的恢复
? 重装备份并恢复到一致性状态 + REDO
小结（续）
? 提高恢复效率的技术
– 检查点技术
? 可以提高系统故障的恢复效率
? 可以在一定程度上提高利用动态转储备份
进行介质故障恢复的效率
– 镜像技术
? 镜像 技术可以改善介质故障的恢复效率
第七章 数据库恢复技术
第三篇 系统篇
? 数据库系统中的数据是由 DBMS统一管理和控制的,
为了适应数据共享的环境, DBMS必须提供数据保
护能力, 以保证数据库中数据的安全可靠和正确有
效 。
? 数据保护
– 安全性
– 完整性
– 并发控制
– 数据库恢复：在某些错误与失败导致当前数据库
状态 （ 数据库内容 ） 不正确时, 恢复数据库到一
个确知的正确数据库状态 。
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.1 事务的基本概念
一、什么是事务
二、如何定义事务
三、事务的特性
一、什么是事务
? 事务 (Transaction)是用户定义的一个数据库操
作序列，这些操作要么全做，要么全不做，是
一个不可分割的工作单位
? 事务和程序是两个概念
– 在关系数据库中，一个事务可以是一条 SQL语句，
一组 SQL语句或整个程序
– 一个应用程序通常包含多个事务
? 事务是恢复和并发控制的基本单位
二、如何定义事务
? 显式定义方式
BEGIN TRANSACTION BEGIN TRANSACTION
SQL 语句 1 SQL 语句 1
SQL 语句 2 SQL 语句 2
。。。。。 。。。。。
COMMIT ROLLBACK
如下面的示例在图书的截止当前销售额超过 $8,000 时，增加支付
给作者的预付款。
BEGIN TRANSACTION
USE pubs
UPDATE titles
SET advance = advance * 1.25
WHERE ytd_sales > 8000
COMMIT
二、如何定义事务
? 隐式方式
当用户没有显式地定义事务时，
DBMS按缺省规定自动划分事务
事务结束
COMMIT
事务正常结束
提交 事务的所有操作（ 读 +更新 ）
事务中所有对数据库的更新 永久 生效
ROLLBACK
事务异常终止
– 事务运行的过程中发生了故障，不能继续执行
回滚事务的所有 更新 操作
– 事务滚回到 开始 时的状态
三、事务的特性 (ACID特性 )
事务的 ACID特性：
? 原子性（ Atomicity）
? 一致性（ Consistency）
? 隔离性（ Isolation）
? 持续性（ Durability ）
1,原子性
? 事务是数据库的逻辑工作单位
– 事务中包括的诸操作要么都做，要么都不做
2,一致性
事务执行的结果必须是使数据库从一个
一致性状态变到另一个一致性状态
一致性状态,
数据库中只包含成功事务提交的结果
不一致状态,
数据库中包含失败事务的结果
一 致性与原子性
银行转帐：从帐号 A中取出一万元，存入帐号 B。
– 定义一个事务，该事务包括两个操作
– 这两个操作要么全做，要么全不做
? 全做或者全不做，数据库都处于一致性状态。
? 如果只做一个操作，数据库就处于不一致性状态 。
B=B+1
A=A-1
BA
3,隔离性
对并发执行而言
一个事务的执行不能被其他事务干扰
? 一个事务内部的操作及使用的数据对其他并发
事务是隔离的
? 并发执行的各个事务之间不能互相干扰
T1的修改被 T2覆盖了！
读 A=16
A←A -3
写回 A=13
① 读 A=16
②
③ A←A -1
写回 A=15
④
T2T1
4,持续性
? 持续性也称永久性（ Permanence）
– 一个事务一旦提交，它对数据库中数据的改
变就应该是永久性的。
– 接下来的其他操作或故障不应该对其执行结
果有任何影响。
事务的特性
? 保证事务 ACID特性是事务处理的任务
? 破坏事务 ACID特性的因素
– 多个事务并行运行时，不同事务的操作交叉执行
– 事务在运行过程中被强行停止
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.2 数据库恢复概述
? 故障是不可避免的
– 计算机硬件故障
– 系统软件和应用软件的错误
– 操作员的失误
– 恶意的破坏
? 故障的影响
– 运行事务非正常中断
– 破坏数据库
数据库恢复概述（续）
? 数据库管理系统对故障的对策
– DBMS提供恢复子系统
– 保证故障发生后，能把数据库中的数据从错
误状态恢复到某种逻辑一致的状态
– 保证事务 ACID
? 恢复技术是衡量系统优劣的重要指标
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
一、事务故障
? 什么是事务故障
– 某个事务在运行过程中由于种种原因未运行至正常
终止点就夭折了
? 事务故障的常见原因
– 输入数据有误
– 运算溢出
– 违反了某些完整性限制
– 某些应用程序出错
– 并行事务发生死锁
– 。。。。
事务故障的恢复
? 发生事务故障时，夭折的事务可能已把
对数据库的部分修改写回磁盘
? 事务故障的恢复,撤消事务（ UNDO）
? 强行回滚（ ROLLBACK）该事务
? 清除该事务对数据库的所有修改，使得
这个事务象根本没有启动过一样
二、系统故障
? 什么是系统故障
– 整个系统的正常运行突然被破坏
– 所有正在运行的事务都非正常终止
– 内存中数据库缓冲区的信息全部丢失
– 数据库不被破坏，但可能处于不正确的状态
系统故障的常见原因
? 操作系统或 DBMS代码错误
? 操作员操作失误
? 特定类型的硬件错误（如 CPU故障）
? 突然停电
系统故障的恢复
? 清除尚未完成的事务对数据库的所有修改
– 系统 重新启动时,恢复程序要强行撤消
（ UNDO）所有未完成事务
? 将缓冲区中已完成事务提交的结果写入数据库
– 系统 重新启动时,恢复程序需要重做
（ REDO）所有已提交的事务
7.3 故障的种类
? 事务故障
? 系统故障
? 介质故障
三、介质故障
? 硬件故障使数据库本身遭到破坏，存储
数据库数据的介质不能读写。这是一种
最严重的失败。
介质故障的常见原因
? 硬件故障
– 磁盘损坏
– 磁头碰撞
– 操作系统的某种潜在错误
– 瞬时强磁场干扰
介质故障的恢复
? 装入 数据库发生介质故障前某个时刻的
数据 副本
? 重做自此时始的所有 成功事务,将这些
事务已提交的结果重新记入数据库
恢复操作的基本原理
? 恢复操作的基本原理,冗余
– 利用 存储在系统其它地方的 冗余数据 来 重建
数据库中已被破坏或不正确的那部分数据
? 恢复的实现技术：复杂
– 一个大型数据库产品，恢复子系统的代码要
占全部代码的 10%以上
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.4 恢复的实现技术
恢复机制涉及的关键问题
1,如何建立冗余数据
? 数据转储（ backup）：数据库的复本
? 登录日志文件（ logging）：日志记录引起
数据库的状态变化的各种修改
2,如何利用这些冗余数据实施数据库恢复
7.4.1 数据转储
一、什么是转储
二、转储的用途
三、转储方法
一、什么是转储
? 转储是指 DBA将整个数据库复制到磁带或另一
个磁盘上保存起来的过程。
? 这些备用的数据文本称为后备副本或后援副本。
转储
故障发生点
转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本 重新运行事务
恢复 ─┼───────┴ －－－－－－－－－－－ － →
三、转储方法
1．静态转储与动态转储
2．海量转储与增量转储
3．转储方法小结
1．静态转储
? 在系统中无运行事务时进行转储
? 转储开始时数据库处于一致性状态
? 转储期间不允许对数据库的任何存取、
修改活动
? 优点,实现简单
? 缺点,降低了数据库的可用性
– 转储必须等用户事务结束
– 新的事务必须等转储结束
利用静态转储副本进行恢复
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本
恢复 ─┼─────── ┥
动态转储
? 转储操作与用户事务并发进行
? 转储期间允许对数据库进行存取或修改
? 优点
– 不用等待正在运行的用户事务结束
– 不会影响新事务的运行
? 动态转储的缺点
– 不能保证副本中的数据正确有效
动态转储
? 利用动态转储得到的副本进行故障恢复
– 需要把动态转储期间各事务对数据库
的修改活动登记下来，建立日志文件
– 后备副本加上日志文件才能把数据库
恢复到某一时刻的正确状态
利用动态转储副本进行恢复
运行事务 故障发生点
动态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本 利用日志文件恢复
恢复 ━━━━━━╋ ━ ━ ━ ┥
利用动态转储副本进行恢复
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
2．海量转储与增量转储
? 海量转储, 每次转储全部数据库
? 增量转储, 只转储上次转储后更新过的数据（日志数据）
? 海量转储与增量转储比较
– 从恢复角度看，使用海量转储得到的后备副本进行恢
复往往更方便
– 但如果数据库很大，事务处理又十分频繁，则增量转
储方式更实用更有效
3．转储方法小结
? 转储方法分类
转储状态
动态转储 静态转储
转储
方式
海量转储 动态海量转储 静态海量转储
增量转储 动态增量转储 静态增量转储
转储策略
? 应定期进行数据转储，制作后备副本。
? 但转储又是十分耗费时间和资源的，不能频繁进行。
? DBA应该根据数据库使用情况确定适当的转储周期和
转储方法。
例：
– 每天晚上进行动态增量转储
– 每周进行一次动态海量转储
– 每月进行一次静态海量转储
7.4 恢复的实现技术
7.4.1 数据转储
7.4.2 登记日志文件
7.4.2 登记日志文件
一、日志文件的内容
二、日志文件的用途
三、登记日志文件的原则
一、日志文件的内容
1,什么是日志文件
日志文件 (log)是用来记录事务对数据库的
更新操作的文件
2,日志文件的格式
以记录为单位的日志文件
以数据块为单位的日志文件
日志文件的内容（续）
3,日志文件内容
– 各个事务的开始 （ BEGIN TRANSACTION） 标记
– 各个事务的结束 （ COMMIT,ROLLBACK） 标记
– 各个事务的所有更新操作
日志文件中的一个日志记录 (log record)
4,基于记录的日志文件
每条日志记录的内容
– 事务标识
– 操作类型（插入、删除或修改）
– 操作对象（记录 ID）
– 更新前数据的旧值（对插入操作而言，此项为空值）
– 更新后数据的新值（对删除操作而言,此项为空值）
注：数据旧值（ Before Image)和数据新值（ After Image）的粒
度可以不同，可能是整个页面（ Page）也可能是某种较小的
单位（如行或元组）。一般地是一个记录。
5,基于数据块的日志文件
每条日志记录的内容
– 事务标识（标明是那个事务）
– 操作对象（ Block NO）
– 更新前数据所在的整个数据块的值（对插入
操作而言，此项为空值）
– 更新后整个数据块的值（对删除操作而言,
此项为空值）
二、日志文件的用途
1．用途
– 进行事务故障恢复
– 进行系统故障恢复
– 协助后备副本进行介质故障恢复
日志文件的用途（续）
2．与静态转储后备副本配合进行介质故障恢复
– 静态转储的数据已是一致性的数据
– 如果静态转储完成后，仍能定期转储日志文件，
则在出现介质故障重装数据副本后，可以利用
这些日志文件副本对已完成的事务进行重做处
理
– 这样不必重新运行那些已完成的事务程序就可
把数据库恢复到故障前某一时刻的正确状态
日志文件的用途（续）
故障发生点
静态转储 运行事务 ↓
正常运行 ─┼──────┼──────────┼──
Ta Tb Tf
登记日志文件
└─────────── ┴ ──
重装后备副本 利用日志文件恢复事务 继续运行
介质故障恢复 ─────────┴ －－－－－ ─ －－－－－－－ ┴──────
登记日志文件
└──────
日志文件的用途（续）
3,介质故障恢复,LOG FILE + 动态转储后备副本
– 动态转储数据库：同时转储同一时点的日志文件
– 后备副本与该日志文件结合起来才能将数据库恢复
到一致性状态。
– 利用这些日志文件副本进一步恢复事务，避免重新
运行事务程序。
三、登记日志文件的原则
? 为保证数据库是可恢复的，登记日志文件时必
须遵循两条原则
– 登记的次序严格按并行事务执行的时间次序
– 必须先写日志文件，后写数据库
? 写日志文件操作：把表示这个修改的日志记录
写到日志文件
? 写数据库操作：把对数据的修改写到数据库中
登记日志文件的原则（续）
? 为什么要先写日志文件
– 写数据库和写日志文件是两个不同的操作
– 在这两个操作之间可能发生故障
– 如果先写了数据库修改，而在日志文件中没有登记
下这个修改，则以后就无法恢复这个修改了
– 如果先写日志，但没有修改数据库，按日志文件恢
复时只不过是多执行一次不必要的 UNDO操作，并
不会影响数据库的正确性
日志文件特征 --日志超前写
? 与数据库缓冲区一样，数据库日志也保存在内存缓
冲区，称为日志缓冲区（ Log Buffer），以后再被永
久地写入外存。
? 永久地保存日志有两种方法：
– 同步写（ Synchronously）：当日志记录增加（缓冲区）
时，日志从内存立即写到外存（数据库日志）（有时日
志是直接写盘，不经过缓冲区）
– 异步写（ Asynchronously）：同数据缓冲区一样，日志写
到外存（数据库日志）或是周期的写或是缓冲区满后写
日志文件特征 --日志超前写
在数据库恢复中事务日志文件起重要的作用, 一旦日志本身被
破坏, 数据库的部分不能被恢复 。 所以, 无 论 同 步 写
（ Synchronously）, 异步写 （ Asynchronously） 都必须怎遵从一
重要的协议,日志超前写 。
日志文件特征 --日志超前写
? 所谓日志超前写, 简单的讲是向数据库写数据之前必须保证
数据库日志已正确的写入, 它准确的含义如下：
? * 在数据库被修改前 （ 也许是由于一个未提交的事务引
起 ）, 数据旧值 （ Before Image） 必须保证已被成功的存入
数据库日志 。 以便恢复时 Undo操作的完成
? * 当事物提交时 （ 或事务已成功提交 ）, 数据新值
（ After Image） 写入数据库之前, 必须保证已被成功的写入
数据库日志 。 以便恢复时 Redo操作的完成
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.5 恢复策略
7.5.1 事务故障的恢复
7.5.2 系统故障的恢复
7.5.3 介质故障的恢复
7.5.1 事务故障的恢复
? 事务故障：事务在运行至正常终止点前被中止
? 恢复方法
– 由恢复子系统利用日志文件撤消（ UNDO）此事务已对数据
库进行的修改
? 事务故障的恢复由系统自动完成，不需要用户干预
事务故障的恢复步骤
1,反向扫描文件日志（即从最后向前扫描日志文件），
查找该事务的更新操作。
2,对该事务的更新操作执行逆操作。即将日志记录中
“更新前的值”（ Befor Image,BI）写入数据库。
– 插入操作,“更新前的值”为空，则相当于做删除操作
– 删除操作，“更新后的值”为空，则相当于做插入操作
– 若是修改操作，则用 BI 代替 AI（ After Image）
事务故障的恢复步骤
3,继续反向扫描日志文件，查找该事务的其他更新操作，
并做同样处理。
4,如此处理下去，直至读到此事务的开始标记，事务故
障恢复就完成了。
? Undo逻辑
Undo逻辑表述如下：
Undo（ T） = Undo（ Undo（ …… （ T）））
撤消事务的影响本身也是一个事务，执行过程中也可
能失败，失败了也要恢复，这意味着 Undo多次对数
据的更新必须保证好象只做了一次 Undo操作
7.5.2 系统故障的恢复
? 系统故障是指由于各种各样的原因导致系统（ OS,DBMS等）
停止工作，需要重新启动系统
? 系统故障造成数据库不一致状态的原因
– 一些未完成事务对数据库的更新已写入数据库
– 一些已提交事务对数据库的更新还留在缓冲区没来得及写入
数据库
? 恢复方法
– 1,Undo 故障发生时未完成的事务
– 2,Redo 已完成的事务
? 系统故障的恢复由系统在 重新启动时调用恢复过程 自动完成，
不需要用户干预
系统故障的恢复 步骤
1,正向扫描日志文件（即从头扫描日志文件）
– Redo队列, 在故障发生前已经提交的事务
T1,T3,T8…..
– Undo队列,故障发生时尚未完成的事务
T2,T4,T5,T6,T7,T9 …...
系统故障的恢复步骤
2,对 Undo队列事务进行 UNDO处理
反向扫描日志文件，对每个 UNDO事务的更
新操作执行逆操作
T2,T4,T5,T6,T7,T9 ……
3,对 Redo队列事务进行 REDO处理
正向扫描日志文件，对每个 REDO事务重新
执行登记的操作
T1,T3,T8…..
7.5.3 介质故障的恢复
1,重装数据库，
使数据库恢复到一致性状态
2,重做已完成的事务
7.5.3 介质故障的恢复
? 恢复步骤
1,装入最新的后备数据库副本，使数据库恢复到最近一
次转储时的一致性状态。
– 对于静态转储的数据库副本，装入后数据库即处于
一致性状态
– 对于动态转储的数据库副本，还须同时装入转储时
刻的日志文件副本，利用与恢复系统故障相同的方
法（即 REDO+UNDO），才能将数据库恢复到一致
性状态。
利用静态转储副本将数据库恢复到一致性状态
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本
恢复 ━━━━━━┥
利用动态转储副本将数据库恢复到一致性状态
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
介质故障的恢复（续）
2,装入有关的日志文件副本，重做已完成的事务。
– 首先扫描日志文件，找出故障发生时已提交的
事务的标识，将其记入重做队列。
– 然后正向扫描日志文件，对重做队列中的所有
事务进行重做处理。即将日志记录中“更新后
的值”写入数据库。
介质故障的恢复（续）
介质故障的恢复需要 DBA介入
? DBA的工作
– 重装最近转储的数据库副本和有关的各日志
文件副本
– 执行系统提供的恢复命令
? 具体的恢复操作仍由 DBMS完成
介质故障的恢复（续）
存储介质失败的一般恢复过程
* 如有可能, 备份当前的日志文件
* 删除被破坏的用户数据库, 并重建该数据库
* 用一个新的存储介质替代已损坏的存储介质
* 装入 （ Load） 最近的数据库备份
* 如果是使用增量备份, 按备份顺序装入备份的日志
* 装入上述第一步备份的当前日志备份 （ 如果有的话 ）
* 重新启动系统,DBMS用系统失败恢复相同的过程，通过
日志文件对刚装入的备份数据库进行更新，使达到最近的一个
正确的数据库状态
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.6 具有检查点的恢复技术
一、问题的提出
二、检查点技术
三、利用检查点的恢复策略
问题的提出
? 两个问题
– 日志文件记录从系统启动以来数据库的状态变化，保存大
量的事务极其数据库状态变化前后值，一般来说是相当大
的一个文件，特别对更新（插入、删除、修改操作）频繁
的系统更是如此。 搜索整个日志将耗费大量的时间
– 对那些已完成（提交）的事务，由于不能确定是否真正的
永久保存到数据库中，对它们未加区分的进行 重做
（ Redo）,相当于将系统启动以来的所有事务再执行一遍，
显然这是 十分费时 的过程，它是使系统恢复效率低的重要
原因。
解决方案
? 所谓检查点是在某一时刻强迫写 缓冲区数据 到数据库, 即
在该时刻将已完成的事务对数据库的影响永久保存
? 系统提供一检查点命令,Checkpoint,系统周期的发出检
查点命令, 也可由用户执行检查点命令
? 一个检查点主要包含下述信息：
– 在日志文件中增加一个, 检查点记录,, 它包含：
? 该时刻未完成事务列表,Undo表
? Undo表中每个事务在日志文件开始记录地址
– 增加一个启动 （ 重新开始 ） 文件, 它存放检查点记录在日志文件
中的地址
设置检查点
? 发出检查点命令时系统的工作：
? * 将日志缓冲区信息写入日志文件 。 由于完成日
志文件写和数据库的写不是一个操作, 即不是一个
事务 。 在完成检查点操作时应先保证日志文件的完
整的保存
* 将检查点记录写入日志文件
* 将数据库缓冲区信息写入数据库
* 将检查点记录在日志文件的地址写入启动文件
利用检查点的恢复策略
? 当事务 T在一个检查点之前提交
T对数据库所做的修改已写入数据库
? 在进行恢复处理时，没有必要对事务 T执
行 REDO操作
利用检查点的恢复策略（续）
Tc(检查点 ) Tf(系统故障 )
REDO
UNDO
UNDO
REDO
T2
T3
T4
T5
不要 REDOT1
利用检查点的 恢复步骤
1,从重新开始文件中找到最后一个检查点记录在
日志文件中的地址
2 由该地址在日志文件中找到最后一个检查点记
录
利用检查点的恢复策略（续）
2.由该检查点记录得到检查点建立时刻所有正在执
行的事务清单 ACTIVE-LIST
– 建立两个事务队列
? UNDO-LIST
? REDO-LIST
– 把 ACTIVE-LIST暂时放入 UNDO-LIST队列，
REDO队列暂为空。
利用检查点的恢复策略（续）
3.从检查点开始正向扫描日志文件，直到日志文
件结束
– 如有新开始的事务 Ti，把 Ti暂时放入 UNDO-
LIST队列
– 如有提交的事务 Tj，把 Tj从 UNDO-LIST队列
移到 REDO-LIST队列
4.对 UNDO-LIST中的每个事务执行 UNDO操作,
对 REDO-LIST中的每个事务执行 REDO操作
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.7 数据库镜像
? 介质故障是对系统影响最为严重的一种故障，
严重影响数据库的可用性
– 介质故障恢复比较费时
– 为预防介质故障,DBA必须周期性地转储数
据库
? 提高数据库可用性的解决方案
– 数据库镜像（ Mirror）
数据库镜像（续）
? 数据库镜像
– DBMS自动把整个数据库或其中的关键数据
复制到另一个磁盘上
– DBMS自动保证镜像数据与主数据的一致性
(图 7.5a)
数据库镜像的用途
? 出现介质故障时
– DBMS自动利用镜像磁盘数据进行数据库的恢复，
不需要关闭系统和重装数据库副本 (图 7.5b)
? 没有出现故障时
– 可用于并发操作 (图 7.5a)
– 一个用户对数据加排他锁修改数据
– 其他用户可以读镜像数据库上的数据
数据库镜像（续）
第七章 数据库恢复技术
7.1 事务的基本概念
7.2 数据库恢复概述
7.3 故障的种类
7.4 恢复的实现技术
7.5 恢复策略
7.6 具有检查点的恢复技术
7.7 数据库镜像
7.8 小结
7.8 小结
? 如果数据库只包含成功事务提交的结果，就说
数据库处于一致性状态。保证数据一致性是对
数据库的最基本的要求。
? 事务是数据库的逻辑工作单位
– DBMS保证系统中一切事务的原子性、一致
性、隔离性和持续性
小结（续）
? DBMS必须对事务故障、系统故障和介质故障
进行恢复
? 恢复中最经常使用的技术：数据库转储和登记
日志文件
? 恢复的基本原理：利用存储在后备副本、日志
文件和数据库镜像中的冗余数据来重建数据库
小结（续）
? 常用恢复技术
– 事务故障的恢复
? UNDO
– 系统故障的恢复
? UNDO + REDO
– 介质故障的恢复
? 重装备份并恢复到一致性状态 + REDO
小结（续）
? 提高恢复效率的技术
– 检查点技术
? 可以提高系统故障的恢复效率
? 可以在一定程度上提高利用动态转储备份
进行介质故障恢复的效率
– 镜像技术
? 镜像 技术可以改善介质故障的恢复效率
