数据库原理:数据库恢复技术
目录
参考:
- 链接1:【最全】《数据库原理及应用》知识点整理+习题 (opens new window)
- 链接2:数据库原理 (opens new window)
- 链接3:数据库原理知识梳理 (opens new window)
# 数据库原理:数据库恢复技术
数据库恢复就是为了将数据库从错误状态恢复到某一已知的正确状态。
# 一、事务的基本概念
事务是用户定义的一个数据库操作序列,这些操作要么全做要么全不做,是一个不可分割的工作单位。例如在关系数据库中,一个事务可以是一条SQL语句、一组SQL语句。在SQL中,定义事务的语句一般有三条:
begin transaction;
commit;
rollback;
2
3
事务通常是以begin transaction开始,以commit或rollback结束。commit表示提交,即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去,事务正常结束。rollback表示回滚,即在事务运行的过程中发生了某种故障,事务不能继续执行,系统将事务中对数据库的所有已完成的操作全部撤销,回滚到事务开始的状态。
事务的特性(ACID):原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持续性(Durability)。
原子性:事务是数据库的逻辑工作单位,事务中包括的操作要么都做,要么都不做
一致性:事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。事务执行过程中出现故障则称这时的数据库处于不一致性状态。
隔离性:一个事务的执行不能被其他事务干扰,即一个事务的内部操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰
持续性(永久性):也称水久性(Permanence),,一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
事务的特性(ACID)可能遭到破坏的因素有:
- 多个事务并行运行时,不同事务的操作交叉执行。
- 事务在运行过程中被强制停止。
# 二、故障的种类
事务内部的故障。
系统故障:如操作系统故障,CPU故障,系统断电。
介质故障:如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。
计算机病毒。
# 三、恢复的实现技术
建立冗余数据最常用的技术是数据转存和登记日志文件。
# 数据转储
转储即DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据称为后备副本。
数据转存的方法分为4类:动态海量存储、动态增量存储、静态海量存储、静态增量存储
静态转储和动态转储:
- 静态转储必须等待正在运行的用户事务结束才能进行;
- 动态转储是指转储期间允许对数据库进行存取或修改,即转储和用户事务可以并发执行。
海量转储和增量转储:
- 海量转储即每次转储全部数据库,
- 增量转储即每次只转储上一次转储后更新的数据。
# 登记日志文件
日志文件是用来记录事务对数据库的更新(增删改)操作的文件。
不同数据库系统采用的日志文件格式并不完全一样,主要有两种格式:以记录为单位的日志文件和以数据块为单位的日志文件。
以记录为单位的日志文件
对以记录为单位的日志文件,日志文件中需要登记的内容包括:
- 各个事务的开始(BEGIN TRANSACTION)标记
- 各个事务的结束(COMMIT或ROLLBACK)标记
- 各个事务的所有更新操作
以上每一条内容记为一个日志记录(log record),每个日志记录的内容主要包括:
- 事务标识(标明是哪个事务)
- 操作的类型(插入、删除或修改)
- 操作对象(记录内部标识)
- 更新前数据的旧值(对插入操作而言,此项为空值)
- 更新后数据的新值(对删除操作而言,此项为空值)
以数据块为单位的日志文件
对以数据块为单位的日志文件,日志记录的内容包括事务标识和被更新的数据块。由于将更新前的整个块和更新后的整个块都放入日志文件中,操作的类型和操作对象等信息就不必放入日志记录中了。
**日志文件的作用:用于事务故障恢复和系统故障恢复,并协助后备副本进行介质故障恢复。**具体如下:
- 事务故障恢复和系统故障恢复必须用日志文件。
- 在动态转储方式中必须建立日志文件,备份副本和日志文件结合起来才能有效地恢复发生故障时的数据库。
- 在静态转储方式中,也可以建立日志文件。当数据库毁坏后可重新装入后备副本,把数据库恢复到转储结束时刻的正确状态,然后利用日志文件,把已完成的事务进行重做处理,对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态。

登记日志文件
为保证数据库是可恢复的,登记日志文件时必须遵循两条规则:
- 登记的次序严格按并发事务执行的时间次序。
- 必须先写日志文件,后写数据库。如果先写了数据库修改,但是没有登记这个日志,那么中途运行故障就无法恢复这个修改了。
# 四、恢复策略
REDO:重做,正向扫描日志文件,对每个REDO事务重新执行日志文件登记的操作
UDNO:撤销,反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作
COMMIT:提交,将事务中所有对数据库的更新写回到磁盘上的物理数据库中,事务正常结束
ROLLBACK:回滚,事务运行的过程中发生了某种故障,事务不能继续执行,系统将事务中对数据库的所有已完成操作全部撤销,回滚到事务开始时的状态
# 事务故障的恢复
事务故障的恢复是由DBMS执行的。恢复步骤是自动完成的,对用户是透明的。具体过程是:
(1)反向扫描日志文件(即从最后向前扫描日志文件),查找该事务的更新操作。
(2)对该事务的更新操作执行逆操作,即将日志记录中“更新前的值”写入数据库:。(来得及或者未来得及写入数据库都没关系)
(3)继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
(4)如此继续,直到读到该事务的开始标记。该事务故障的恢复就完成了。
# 系统故障的恢复
系统故障的恢复操作是指撒销(UNDO)故障发生时未完成的事务,重做(REDO)已完成的事务。系统的恢复步骤是:
(1)正向扫描日志文件,找出在故障发生前已经提交的事务(这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录),将其事务标记记入REDO队列;同时找出故障发生时尚未完成的事务(这些事务只有BEGIN TRANSACTION记录,无相应的COMMIT记录),将其事务标记记入UNDO队列
(2)对撤销队列中的各个事务执行UNDO操作
(3)对重做队列中的各个事务执行REDO操作
为什么要REDO?考虑已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库(磁盘)。
# 介质故障的恢复
介质故障是最严重的一种故障。恢复方法是重装数据库,重做已完成的事务。具体过程是:
(1)装入最新的数据库后备副本(离故障发生时刻最近的转储副本),使数据库恢复到最近一次转储时的一致性状态。
(2)装入相应的日志文件副本(转储结束时刻的日志文件副本),重做已完成的事务,即扫描日志文件找出需要重做和撤销的事务。
(3)启动系统恢复命令,由DBMS完成恢复功能,即重做已完成的事务。