第十章 数据库恢复技术

第十章 数据库恢复技术

10.1 事务的基本概念

  • 事务
    • 事务是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位。例
    • 事务的特性(ACID特性(ACID properties))
      • 原子性(Atomicity)
        • 事务是数据库的逻辑工作单位,事务中包括的诸操作要么都做,要么都不做。
      • 一致性(Consistency)
        • 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
        • 一致性状态:数据库中只包含成功事务提交的结果。
        • 不一致状态:数据库系统运行中发生故障,有些事务尚未完成就被迫中断;这些未完成事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种工确的状态。
      • 隔离性(Isolation)
        • 一个事务的执行不能被其他事务干扰。即一个事务的内部操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。
      • 特续性(Durability)
        • 持续性也称永久性(Permanence),指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
    • 保证事务ACID特性是事务管理的重要任务。事务ACID特性可能遭到破坏的因素有:
      • 多个事务并行运行时,不同事务的操作交叉执行;
      • 事务在运行过程中被强行停止。

10.2 数据库恢复概述

  • 故障是不可避免的,故障主要包括:
    • 计算机硬件故障、软件的错误、操作员的失误、恶意的破坏等。
  • 故障对数据库的影响主要表现为:
    • 运行事务非正常中断、影响数据库中数据的正确性、数据库全部或部分丢失数据等。
  • 数据库恢复的作用:
    • 把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的功能。

10.3 故障的种类

  • 事务内部的故障
    • 事务内部的故障有的是可以通过事务程序本身发现的,有的是非预期的,不能由事务程序处理。
    • 事务内部更多的故障是非预期的,是不能由应用程序处理的
  • 系统故障
    • 指造成系统停止运转的任何事件,使得系统要重新启动
    • 系统故障的恢复
      • 表现一:发生系统故障时,一些尚未完成的事务的结果可能已送入物理数据库,造成数据库可能处于不正确状态。
      • 恢复策略:系统重新启动时,恢复程序让所有非正常终止的业务回滚,强行撤消(UNDO)所有未完成事务。
      • 表现二:发生系统故障时,有些已完成的事务可能有一部分甚至全部留在缓冲区,尚未写回到磁盘上的物理数据库中,系统故障使得这些事务对数据库的修改部分或全部丢失。
      • 恢复策略:系统重新启动时,恢复程序需要重做(REDO)所有已提交的事务。
  • 介质故障
    • 介质故障称为硬故障,指外存故障,如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。
    • 故障表现:
      • 破坏数据库或部分数据库,并影响正在存取这部分数据的所有事务,介质故障比前两类故障的可能性小得多。,但破坏性大得多
  • 计算机病毒
    • 计算机病毒是一种可繁殖、传播并对计算机造成破坏的计算机程序。
    • 计算机病毒的特点:
      • 隐蔽性
      • 潜伏性
      • 传染性
      • 破坏性
      • 破坏性
      • 寄生性
    • 数据库一旦被病毒破坏仍要用恢复技术把数据库加以恢复。

10.4 恢复的实现技术

  • 恢复机制涉及的两个关键问题是:
    • 如何建立冗余数据
    • 以及如何利用这些冗余数据实施数据库恢复。
    • 建立冗余数据最常用的技术是
      • 数据转储
      • 登记日志文件(logging)

10.4.1 数据存储

数据转储是数据库恢复中采用的基本技术。所谓转储即数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备用的数据称为后备副本(backup)或后援副本。

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

  • 存储方法
    • 静态存储
      • 在系统中无运行事务时进行的转储操作,即转储期间不允许对数据库进行任何存取、修改活动。
      • 优点:
        • 实现简单。
      • 缺点:
        • 降低了数据库的可用性,因为转储必须等待正运行的用户事务结束,新的事务必须等转储结束。
    • 动态存储
      • 转储操作与用户事务并发进行,转储期间允许对数据库进行存取或修改。
      • 优点
        • 不用等待正在运行的用户事务结束,不会运行影响事务的运行
      • 缺点:
        • 不能保证副本中的数据正确有效。
    • 海量转储
      • 每次转储全部数据库
    • 增量转储
      • 只转储上次转储后更新过的数据

10.4.2 登记日志文件

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

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

    1. 日志文件的格式

      以记录为单位的日志文件和以数据块为单位的日志文件两种

      • 以记录为单位的日志文件需要登记的内容:
        • 各个事务的开始标记(BEGIN TRANSACTION);
        • 各个事务的结束标记(COMMIT或ROLLBACK);
        • 各个事务的所有更新操作;
      • 每个日志记录的内容主要包括:
        • 事务标识(标明是哪个事务)。
        • 操作的类型(插入、删除或修改)。
        • 操作对象(记录内部标识)。
        • 更新前数据的旧值(对插入操作而言,此项为空值)。
        • 更新后数据的新值(对删除操作而言,此项为空值)。
    2. 日志文件的作用

      用于事务故障恢复和系统故障恢复,并协助后备副本进行介质故障恢复,具体为:

      • 事务故障恢复和系统故障恢复必须用日志文件。
      • 在动态转储方式中必须建立日志文件,后备副本和日志文件结合起来才能有效地恢复数据库。
      • 在静态转储方式中也可以建立日志文件,当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态,然后利用日志文件把已完成的事务进行重做处理,对故障发生时尚未完成的事务进行撤销处理。
  • 登记日志文件
    • 为保证数据库是可恢复的,登记日志文件时必须遵循两条原则:
      • 登记的次序严格按并发事务执行的时间次序。
      • 必须先写日志文件,后写数据库。

10.5 恢复策略

10.5.1 事务故障的恢复

  • 事务故障:

    • 事务在运行至正常终止点前被终止,恢复子系统利用日志文件撤销(UND0)此事务已对数据库进行的修改。
  • 事务故障的恢复步骤是:

    1. 反向扫描日志文件(即从最后向前扫描日志文件),查找该事务的更新操作。

    2. 对该事务的更新操作执行逆操作,即将日志记录中"更新前的值"写入数据库。

      • 插入操作,"更新前的值"为空,则相当于做删除操作。
      • 删除操作,"更新后的值"为空,则相当于做插入操作
      • 修改操作,则相当于用修改前1修改后值。
    3. 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。

    4. 如此处理下去,直至读到此事务的开始标记,事务故障恢复就完成了。

10.5.2 系统故障的恢复

  • 前面已讲过,系统故障造成数据库不一致状态的原因有两个,

    • 一是未完成事务对数据库的更新可能已写入数据库,
    • 二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。
  • 恢复操作就

    • 撤销故障发生时未完成的事务
    • 重做已完成的事务。
  • 糸统故障的恢复步骤:

    1. 正向扫描日志文件(即从头扫描日志文件)

      找出在故障发生前已经提交的事务,加入重做队列,找出故障发生时尚未完成的事务,加入撤销队列。

    2. 对撤销队列事务进行撤销处理

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

    3. 对重做队列事务进行重做处理

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

10.5.3 介质故障的恢复

介质故障后磁盘上的物理数据和日志文件被破坏,这是最严重的一种故障,恢复方法是重装数据库,然后重做已完成的事务

  • 恢复步骤

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

      对于静态转储的数据库副本,装入后数据库处于一致性状态

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

    2. 装入相应的日志文件副本(转储结束时刻的日志文件副本),重做已完成的事务。

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

10.6 具有检查点的恢复技术

  • 解决问题

    • 一是搜索整个日志将耗费大量的时间,
    • 二是很多需要重做处理的事务实际上已经将它们的更新操作结果写到了数据库中,然而恢复子系统又重新执行了这些操作,浪费了大量时间。
  • 解决方案

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

    1. 检查点记录的内容

      1. 建立检查点时刻所有正在执行的事务清单。
      2. 这些事务最近一个日志记录的地址。
      3. 重新开始文件的内容。
      4. 记录各个检查点记录在日志文件中的地址。
    2. 动态维护日志文件的方法

      周期性地执行建立检查点、保存数据库状态的操作。

      1. 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上。
      2. 在日志文件中写入一个检查点记录。
      3. 将当前数据缓冲区的所有数据记录写入磁盘的数据库中。
      4. 把检查点记录在日志文件中的地址写入一个重新开始文件。
  • 系统使用检查点方法进行恢复的步骤是:

    1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录。
    2. 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。
      • 这里建立两个事务队列:
        • UNDO-LIST:需要执行UNDO操作的事务集合;·
        • REDO-LIST:需要执行REDO操作的事务集合。把ACTIVE-LIST暂时放入UNDO-LIST队列,REDO队列暂为空。
    3. 从检查点开始正向扫描日志文件。
      1. 如有新开始的事务T,把T;暂时放入UNDO-LIST队列;
      2. 如有提交的事务T,把T从UNDO-LIST队列移到REDO-LIST队列;直到日志文件结束。
    4. 对UNDO-LIST中的每个事务执行UNDO操作,对REDO-LIST中的每个事务执行REDO操作。

10.7 数据库镜像

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

相关推荐
FIN技术铺1 小时前
问:数据库的六种锁机制实践总结?
数据库·sql·oracle
程序员劝退师_1 小时前
优惠券秒杀的背后原理
java·数据库
Gauss松鼠会1 小时前
GaussDB全密态数据库等值查询
数据库·oracle·gaussdb
JSUITDLWXL1 小时前
在Oracle数据中更新整个对象和更新对象的某几个字段时,他们的锁是相同的吗
数据库·oracle
杏花春雨江南1 小时前
ddl/dml/dcl
数据库·oracle
Matrix702 小时前
HBase理论_HBase架构组件介绍
大数据·数据库·hbase
不太灵光的程序员2 小时前
【HBase分布式数据库】第七章 数据的导入导出 importtsv导入数据
数据库·分布式·hbase
Mephisto.java2 小时前
【大数据学习 | HBASE高级】region split机制和策略
数据库·学习·hbase
Lucifer三思而后行2 小时前
YashanDB YAC 入门指南与技术详解
数据库·后端
大气层煮月亮2 小时前
python调用MySql详细步骤
数据库·mysql