恢复技术
目标：基本概念的理解掌握
事务⭐️
基本定义
什么是事务
- 事务(Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。
- 事务和程序是两个概念：在关系数据库中，一个事务可以是一条SQL语句， 一组SQL语句或整个程序。一个应用程序通常包含多个事务。
- 事务是恢复和并发控制的基本单位
如何定义事务
BEGIN TRANSACTION BEGIN TRANSACTION SQL 语句1 SQL 语句1 SQL 语句2 SQL 语句2 。。。。。 。。。。。 COMMIT ROLLBACK
- COMMIT
- 事务正常结束
- 提交事务的所有操作（读+更新）
- 事务中所有对数据库的更新永久生效
- ROLLBACK
- 事务异常终止
- 事务运行的过程中发生了故障，不能继续执行，回滚事务的所有更新操作
- 事务滚回到开始时的状态
事务的特性（ACID特性）⭐️
- 原子性（Atomicity）/ˌadəˈmisədē/：
事务是数据库的逻辑工作单位
事务中包括的诸操作要么都做，要么都不做
- 一致性（Consistency）
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
一致性状态： 数据库中只包含成功事务提交的结果 不一致状态： 数据库中包含失败事务的结果
- 隔离性（Isolation）/ˌīsəˈlāSH(ə)n/
对并发执行而言 一个事务的执行不能被其他事务干扰
一个事务内部的操作及使用的数据对其他并发事务是隔离的
并发执行的各个事务之间不能互相干扰
- 持续性（Durability ）/ˌd(y)o͝orəˈbilədē/
持续性也称永久性（Permanence）
一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。
接下来的其他操作或故障不应该对其执行结果有任何影响。
故障种类⭐️
事务故障
什么是事务故障
- 某个事务在运行至正常终止点前被中止
事务故障的常见原因
- 输入数据有误 、运算溢出、违反了某些完整性限制、某些应用程序出错、并行事务发生死锁
事务故障的恢复
- 发生事务故障时，夭折的事务可能已把对数据库的部分修改写回磁盘
- 事务故障的恢复：撤消事务（UNDO）
- 强行回滚（ROLLBACK）该事务
- 清除该事务对数据库的所有修改，使得这个事务像根本没有启动过一样
系统故障
什么是系统故障
- 整个系统的正常运行突然被破坏
- 所有正在运行的事务都非正常终止
- 内存中数据库缓冲区的信息全部丢失
- 外部存储设备上的数据未受影响
系统故障的常见原因
- 操作系统或DBMS代码错误、操作员操作失误、特定类型的硬件错误（如CPU故障）、突然停电
系统故障的恢复
- 清除尚未完成的事务对数据库的所有修改
- 系统重新启动时，恢复程序要强行撤消 （UNDO）所有未完成事务
- 将缓冲区中已完成事务提交的结果写入数据库
- 系统重新启动时，恢复程序需要重做 （REDO）所有已提交的事务
介质故障
什么是介质故障
- 硬件故障使存储在外存中的数据部分丢失或全部丢失
- 介质故障比前两类故障的可能性小得多， 但破坏性大得多
介质故障的常见原因
- 硬件故障（磁盘损坏、磁头碰撞、操作系统的某种潜在错误、瞬时强磁场干扰）
恢复技术
恢复机制涉及的关键问题：
- 如何建立冗余数据
- 数据转储（backup）
- 登记日志文件（logging）
- 如何利用这些冗余数据实施数据库恢复
数据转储
什么是数据转储
- 数据转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程。
- 这些备用的数据文本称为后备副本或后援副本
数据转储方法
- 静态转储：在系统中无运行事务时进行转储
- 动态转储：转储操作与用户事务并发进行
需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件
后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态
- 海量转储：每次转储全部数据库
- 增量转储：只转储上次转储后更新过的数据
日志文件⭐️
什么是日志文件
- 日志文件(log)是用来记录事务对数据库的更新操作的文件
日志文件的格式
- 以记录为单位的日志文件
- 以数据块为单位的日志文件
日志文件的用途
- 进行事务、系统故障恢复
- 动态转储必须使用日志
- 转储后备副本配合进行介质故障恢复
登记日志文件的原则
- 登记的次序严格按并发事务执行的时间次序
- 必须先写日志文件，后写数据库
恢复方法
事务故障的恢复
- 事务故障：事务在运行至正常终止点前被中止(日志中有begin 没有commit)
- 由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改
- 事务故障的恢复由系统自动完成，不需要用户干预
事务故障的恢复步骤
- 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
- 对该事务的更新操作执行逆操作。即将日志记录中 “更新前的值”（Befor Image, BI）写入数据库。
- 插入操作， “更新前的值”为空，则相当于做删除操作
- 删除操作，“更新后的值”为空，则相当于做插入操作
- 若是修改操作，则用BI 代替 AI（After Image）
- 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
- 如此处理下去，直至读到此事务的开始标记（begin），事务故障恢复就完成了。
系统故障的恢复
系统故障造成数据库不一致状态的原因
- 一些未完成事务对数据库的更新已写入数据库
- 一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
恢复方法
- Undo 故障发生时未完成的事务
- Redo 已完成的事务
系统故障的恢复由系统在重新启动时自动完成，不需要用户干预
系统故障的恢复步骤
- 正向扫描日志文件（即从头扫描日志文件）
- Redo队列: 在故障发生前已经提交的事务
- Undo队列:故障发生时尚未完成的事务
- 对Undo队列事务进行UNDO处理
- 反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作
- 对Redo队列事务进行REDO处理
- 正向扫描日志文件，对每个REDO事务重新执行登记的操作
介质故障的恢复
介质故障的恢复需要DBA介入
- 重装最近转储的数据库副本和有关的各日志文件副本
- 执行系统提供的恢复命令
具体的恢复操作仍由DBMS完成
恢复方法
- 重装数据库，使数据库恢复到一致性状态
- 重做已完成的事务
介质故障的恢复步骤
- 装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。
- 利用静态、动态转储恢复到转储的状态
- 装入有关的日志文件副本，重做已完成的事务
- 从转储时刻开始，扫描日志，故障发生时已提交的事务，REDO事务
具有检查点的恢复技术
两个问题
- 搜索整个日志将耗费大量的时间
- REDO处理：重新执行，浪费了大量时 间
解决方案
- 在日志文件中增加检查点记录 （checkpoint）
检查点记录的内容
- 建立检查点时刻所有正在执行的事务清单
- 这些事务最近一个日志记录的地址
- 增加重新开始文件
重新开始文件的内容
- 记录各个检查点记录在日志文件中的地址
- 恢复子系统在登录日志文件期间动态地维护日志
利用检查点的恢复方法
当事务T在一个检查点之前提交，T对数据库所做的修改已写入数据库。
在进行恢复处理时，没有必要对事务T执行REDO操作
利用检查点的恢复步骤
- 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
- 由该检查点记录得到检查点建立时刻所有正在 执行的事务清单ACTIVE-LIST
- 建立两个事务队列：UNDO-LIST、REDO-LIST
- 把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO-LIST队列暂为空。
- 从检查点开始正向扫描日志文件，直到日志文件结束
- 有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列
- 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列
- 对UNDO-LIST中的每个事务执行UNDO操作, 对REDO-LIST中的每个事务执行REDO操作
小结⭐️
- 如果数据库只包含成功事务提交的结果，就说数据库处于一致性状态。保证数据一致性是对数据库的最基本的要求。
- 事务是数据库的逻辑工作单位
- DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性
- DBMS必须对事务故障、系统故障和介质故障进行恢复
- 恢复中最经常使用的技术：数据库转储和登记日志文件
- 恢复的基本原理：利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库
- 常用恢复技术
- 事务故障的恢复
- UNDO
- 系统故障的恢复
- UNDO + REDO
- 介质故障的恢复
- 重装备份并恢复到一致性状态 + REDO
- 提高恢复效率的技术
- 检查点技术
- 可以提高系统故障的恢复效率
- 可以在一定程度上提高利用动态转储备份 进行介质故障恢复的效率
- 镜像技术
- 镜像技术可以改善介质故障的恢复效率
