【课堂笔记】《数据库系统概论（第5版）》-第10章：数据库恢复技术

第10章：数据库恢复技术

10.1 事务的基本概念

• 事务的定义

  用户定义的一个数据库操作序列，其中的操作要么全做、要么全不做，是一个不可分割的工作单位；

  一般来讲，一个程序中包含多个事务；

  与事务有关的SQL语句主要有三条：

  begin transaction;
  commit;
  rollback;
  

  commit表示提交事务的所有操作，即将事务对数据库的更新写到磁盘上；

  rollback表示事务不能继续进行，撤销事务对数据库的所有操作，将数据库回滚到事务开始时的状态；

• 事务的ACID特性

  • 原子性（Atomicity）

    事务是数据库工作的逻辑单位，其中的操作要么全做、要么全不做；

  • 一致性（Consistency）

    数据库中只包含成功事务提交的结果时，就说数据库处于一致性状态；

    事务的执行结果必须使数据库从一个一致性状态到另一个一致性状态；

    例如未完成的事务有部分结果写入数据库，这时候数据库处于不一致的状态；

  • 隔离性（Isolation）

    一个事务内部的操作及使用的数据对其他并发事务是隔离的

    并发执行的各个事务之间互不干扰；

  • 持续性（Durability）

    也称永久性，指的是事务一旦提交，对数据库中数据的改变是永久的；

  事务是并发控制和恢复的基本单位；

  可能造成事务的ACID特性被破坏的因素有：

  • 并行运行时，不同事务的操作交叉执行；

    需要保证多个事务交叉运行时，不影响原子性；

  • 事务在运行过程中被强制停止；

    保证被强制停止的事务不对数据库和其他事务造成影响；

10.2 数据库恢复概述

硬件故障、软件错误、操作员失误、恶意破坏，不可避免；

轻则影响数据正确性，重则破坏数据库，使数据库丢失；

因此，数据库管理系统必须有把数据库从错误的状态恢复到某一已知的正确状态的功能；

恢复子系统是数据库管理系统的重要组成部分、衡量系统性能优劣的重要指标；

10.3 故障的种类

1. 事物内部的故障

   有的可以通过程序自身发现，大多数则是非预期的（运算溢出、死锁等）、不能由程序自身处理；

   事务处现故障意味着没有到达预期的终点（commit、rollback），需要强行回滚这些事务，被称为事务撤销（UNDO）；

2. 系统故障（软故障）

   指造成系统停止运转的任何事件、使得系统需要重新启动；

   需要撤销所有未完成的事务、**重做（REDO）**所有已提交的事务；

3. 介质故障（硬故障）

   磁盘损坏、磁头碰撞、瞬时强磁场干扰等；

   破坏部分数据库、影响正在存取这部分数据的所有事务；

   可能性小、破坏性大；

4. 计算机病毒

各类故障对数据库有两种可能的影响：数据库本身被破坏、数据不正确；

恢复的基本原理：冗余；

10.4 恢复的实现技术

恢复机制涉及的两个关键问题：如何建立冗余数据、如何利用冗余数据恢复数据库；

建立冗余数据最常用的技术：数据转储、登记日志文件；

10.4.1 数据转储

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

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

数据库遭到破坏后可以将后备副本重新装入；

重装后备副本只能将数据库恢复到转储时的状态；

要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务；

转储可以分为静态转储和动态转储：

• 静态转储：

  在系统中无运行事务时进行的转储操作，转储开始时数据库处于一致性状态，转储期间不允许对数据库的任何存取、修改活动，得到的一定是一个数据一致性的副本，优点：实现简单，缺点：降低了数据库的可用性，转储必须等待正运行的用户事务结束，新的事务必须等转储结束。

• 动态转储：

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

  转储期间允许对数据库进行存取或者修改；

  优点：

  • 无需等待现有事务结束；
  • 不影响新事务的进行；

  缺点：

  • 无法保证副本中的数据的正确有效；
  • 需要对转储期间各事务对数据库的操作记录下来建立日志文件；
  • 通过副本和日志文件将数据库恢复到正确状态；

转储还可以分为海量转储和增量转储，前者指的是转储全部数据库，后者指的是每次转储更新过的数据；

海量、增量和静态、动态一共组合出四种转储方法；

10.4.2 登记日志文件

1. 日志文件的格式和内容

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

   按格式主要分为以记录为单位的日志文件和以数据块为单位的日志文件；

   以记录为单位的日志文件的内容

   • 各个事务的开始标记(BEGIN TRANSACTION)
   • 各个事务的结束标记(COMMIT或ROLLBACK)
   • 各个事务的所有更新操作
     以上均作为日志文件中的一个日志记录；

   以记录为单位的日志文件，每条日志记录的内容

   • 事务标识（标明是哪个事务）
   • 操作类型（插入、删除或修改）
   • 操作对象（记录ID、Block NO.）
   • 更新前数据的旧值（对插入操作而言，此项为空值）
   • 更新后数据的新值（对删除操作而言, 此项为空值）

   以数据块为单位的日志文件，每条记录的内容

   • 事务标识
   • 被更新的数据块

2. 日志文件的作用

   日志文件的用途：

   • 进行事务的故障恢复
   • 进行系统的故障恢复
   • 协助后备副本进行介质故障恢复

   在静态转储方式中，也可以建立日志文件

   • 当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态
   • 利用日志文件，把已完成的事务进行重做处理
   • 对故障发生时尚未完成的事务进行撤销处理
   • 不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态

3. 登记日志文件

   登记日志文件的原则：

   1. 登记的次序严格按照并发事务执行的时间顺序；
   2. 先写日志文件，后写数据库；

10.5 恢复策略

10.5.1 事务故障的恢复

由恢复子系统利用日志文件撤消（UNDO）此事务已对数据库进行的修改；

事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预；

步骤：

• 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作；

• 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值” 写入数据库；

  • 插入操作， “更新前的值”为空，则相当于做删除操作
  • 删除操作，“更新后的值”为空，则相当于做插入操作
  • 若是修改操作，则相当于用修改前值代替修改后值

• 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理；

• 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了；

10.5.2 系统故障的恢复

系统故障造成数据库不一致状态的原因:

• 未完成事务对数据库的更新可能已写入数据库；
• 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库；

恢复方法

• Undo 故障发生时未完成的事务；
• Redo 已完成的事务；

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

系统故障恢复的步骤：

• 正向扫描日志文件（即从头扫描日志文件）

  • 重做(REDO) 队列: 在故障发生前已经提交的事务
    这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录

  • 撤销 (UNDO)队列: 故障发生时尚未完成的事务
    这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录

• 对撤销(UNDO)队列事务进行撤销(UNDO)处理

  • 反向扫描日志文件，对每个撤销事务的更新操作执行逆操作
  • 即将日志记录中“更新前的值”写入数据库

• 对重做(REDO)队列事务进行重做(REDO)处理

  • 正向扫描日志文件，对每个重做事务重新执行登记的操作
  • 即将日志记录中“更新后的值”写入数据库

10.5.3 介质故障的恢复

重装数据库，然后重做已经完成的事务；

• 装入最新的后备数据库副本(离故障发生时刻最近的转储副本) ，使数据库恢复到最近一次转储时的一致性状态

  • 对于静态转储的数据库副本，装入后数据库即处于一致性状态
  • 对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。

• 装入有关的日志文件副本(转储结束时刻的日志文件副本) ，重做已完成的事务。

  • 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
  • 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。

介质故障的恢复需要数据库管理员的介入，但数据库管理员只需要重装最近转储的数据库副本和日志文件副本，然后执行恢复命令，具体的操作仍由数据库管理系统完成；

10.6 具有检查点的恢复技术

上面方法的问题：

• 搜索整个日志将耗费大量的时间
• 重做处理：重新执行，浪费了大量时间

具有检查点（checkpoint）的恢复技术

• 在日志文件中增加检查点记录（checkpoint）
• 增加重新开始文件
• 恢复子系统在登录日志文件期间动态地维护日志

检查点记录的内容

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

重新开始文件的内容

• 记录各个检查点记录在日志文件中的地址

动态维护日志文件的方法

周期性地执行如下操作：建立检查点，保存数据库状态，具体步骤是：

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

恢复子系统可以定期或不定期地建立检查点，保存数据库状态

• 定期
  • 按照预定的一个时间间隔，如每隔一小时建立一个检查点
• 不定期
  • 按照某种规则，如日志文件已写满一半建立一个检查点

使用检查点方法可以改善恢复效率

• 当事务T在一个检查点之前提交，T对数据库所做的修改已写入数据库
• 写入时间是在这个检查点建立之前或在这个检查点建立之时
• 在进行恢复处理时，没有必要对事务T执行重做操作

利用检查点的恢复步骤

• 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录；

• 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST

  建立两个事务队列

  • UNDO-LIST
  • REDO-LIST

  把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。

• 从检查点开始正向扫描日志文件，直到日志文件结束

  • 如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列
  • 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列;直到日志文件结束

• 对UNDO-LIST中的每个事务执行UNDO操作，对REDO-LIST中的每个事务执行REDO操作

10.7 数据库镜像

介质故障是对系统影响最为严重的一种故障，严重影响数据库的可用性

• 介质故障恢复比较费时
• 为预防介质故障，数据库管理员必须周期性地转储数据库

提高数据库可用性的解决方案

• 数据库镜像（Mirror）

数据库镜像

• 数据库管理系统自动把整个数据库或其中的关键数据复制到另一个磁盘上
• 数据库管理系统自动保证镜像数据与主数据的一致性，每当主数据库更新时，数据库管理系统自动把更新后的数据复制过去

出现介质故障时

• 可由镜像磁盘继续提供使用
• 同时数据库管理系统自动利用镜像磁盘数据进行数据库的恢复
• 不需要关闭系统和重装数据库副本

没有出现故障时

• 可用于并发操作
• 一个用户对数据加排他锁修改数据，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁

频繁地复制数据自然会降低系统运行效率

• 在实际应用中用户往往只选择对关键数据和日志文件镜像
• 不是对整个数据库进行镜像