关系数据库——数据库恢复

举报
兔老大 发表于 2021/04/20 00:50:17 2021/04/20
【摘要】 实现技术   恢复操作的基本原理:冗余 恢复机制涉及的两个关键问题 如何建立冗余数据 数据转储(backup)登录日志文件(logging) 如何利用这些冗余数据实施数据库恢复   数据转储   数据转储定义: 转储是指DBA将整个数据库复制到其他存储介质上保存起来的过程,备用的数据称为后备副本或后援副本 如何使用...

实现技术

 

  • 恢复操作的基本原理:冗余 
  • 恢复机制涉及的两个关键问题
  1. 如何建立冗余数据
    • 数据转储(backup
    • 登录日志文件(logging
  2.  如何利用这些冗余数据实施数据库恢复

 

数据转储

 

  • 数据转储定义:

转储是指DBA将整个数据库复制到其他存储介质上保存起来的过程,备用的数据称为后备副本或后援副本

  • 如何使用
    1. 数据库遭到破坏后可以将后备副本重新装入
    2. 重装后备副本只能将数据库恢复到转储时的状态
  • 转储方法
    1. 静态转储与动态转储
    2. 海量转储与增量转储

静态转储:

1)定义:在系统中无事务运行时进行的转储操作。转储开始的时刻数据库处于一  致性状态,而转储不允许对数据库的任何存取、修改活动。静态转储得到的一定是一个数据一致性的副本。

2)优点:实现简单

3)缺点:降低了数据库的可用性

转储必须等待正运行的用户事务结束才能进行;新的事务必须等待转储结束才能执行

动态转储:

            1)定义:转储期间允许对数据库进行存取或修改。转储和用户事务可以并发执行。

            2)优点:不用等待正在运行的用户事务结束;不会影响新事务的运行。

            3)实现:必须把转储期间各事务对数据库的修改活动登记下来,建立日志文件后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态。

海量转储:

            1)定义:每次转储全部数据库

            2)特点:从恢复角度,使用海量转储得到的后备副本进行恢复更方便一些。

增量转储:

            1)定义:每次只转储上一次转储后更新过的数据

            2)特点:如果数据库很大,事务处理又十分频繁,则增量转储方式更实用更有效。

 

日志文件

 

1、什么是日志文件

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

2、日志文件的格式

1)以记录为单位:

日志文件中需要登记的内容包括:

    • 各个事务的开始标记(BEGIN TRANSACTION)
    • 各个事务的结束标记(COMMITROLLBACK)
    • 各个事务的所有更新操作

     以上均作为日志文件中的一个日志记录                   

每个日志记录的内容:

  • 事务标识(标明是哪个事务)
  • 操作类型(插入、删除或修改)
  • 操作对象(记录内部标识)
  • 更新前数据的旧值(对插入操作而言,此项为空值)
  • 更新后数据的新值(对删除操作而言, 此项为空值)

 

2)以数据块为单位

日志记录内容包括:

事务标识(标明是哪个事务)

 被更新的数据块

3、日志文件的作用

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

1)事务故障恢复和系统故障恢复必须用日志文件

2)在动态转储方式中必须建立日志文件,后备副本和日志文件结合起来才能有效地恢复数据库

3)静态转储方式中也可以建立日志文件(重新装入后备副本,然后利用日志文件把已完成的事务进行重做,对未完成事务进行撤销)

4、登记日志文件:

  • 基本原则
    1. 登记的次序严格按并行事务执行的时间次序
    2. 必须先写日志文件,后写数据库

为什么要先写日志文件?

1)写数据库和写日志文件是两个不同的操作,在这两个操作之间可能发生故障

2)如果先写了数据库修改,而在日志文件中没有登记下这个修改,则以后就无法恢复这个修改了

3)如果先写日志,但没有修改数据库,按日志文件恢复时只不过是多执行一次不必要的UNDO操作,并不会影响数据库的正确性

 

恢复策略

 

事务故障的恢复

  • 事务故障:事务在运行至正常终止点前被终止
  • 恢复方法
    1. 由恢复子系统应利用日志文件撤消(UNDO)此事务已对数据库进行的修改
  • 事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预
  • 事务故障的恢复步骤

1. 反向扫描文件日志,查找该事务的更新操作。

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

 

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

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

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

系统故障的恢复

  • 系统故障造成数据库不一致状态的原因
    1. 未完成事务对数据库的更新已写入数据库
    2. 已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
  • 恢复方法
    1. Undo 故障发生时未完成的事务
    2. Redo 已完成的事务
  • 系统故障的恢复由系统在重新启动时自动完成,不需要用户干预
  • 系统故障的恢复步骤

1. 正向扫描日志文件

      • 重做(REDO) 队列: 在故障发生前已经提交的事务
        • 这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录
      • 撤销 (Undo)队列: 故障发生时尚未完成的事务
        •  这些事务只有BEGIN TRANSACTION记录,无相应的COMMIT记录

2. 对撤销(Undo)队列事务进行撤销(UNDO)处理

      • 反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作

3. 对重做(Redo)队列事务进行重做(REDO)处理

      • 正向扫描日志文件,对每个REDO事务重新执行登记的操作

介质故障的恢复

恢复步骤

重装数据库

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

 装入有关的日志文件副本,重做已完成的事务。

  • 首先扫描日志文件,找出故障发生时已提交的事务的标识,将其记入重做队列。
  • 然后正向扫描日志文件,对重做队列中的所有事务进行重做处理。
  • 介质故障的恢复需要DBA介入
  • DBA的工作
    1. 重装最近转储的数据库副本和有关的各日志文件副本
    2. 执行系统提供的恢复命令,具体的恢复操作仍由DBMS完成

检查点

  • 利用日志技术进行数据库恢复存在两个问题
    1. 搜索整个日志将耗费大量的时间
    2. REDO处理:事务实际上已经执行,又重新执行,浪费了大量时间
  • 具有检查点(checkpoint)的恢复技术
    1. 在日志文件中增加检查点记录(checkpoint
    2. 增加重新开始文件,并让恢复子系统在登录日志文件期间动态地维护日志
  • 检查点记录的内容
    1. 建立检查点时刻所有正在执行的事务清单
    2. 这些事务最近一个日志记录的地址
  • 重新开始文件的内容
    1. 记录各个检查点记录在日志文件中的地址

  • 动态维护日志文件的方法

周期性地执行如下操作:建立检查点,保存数据库状态。

具体步骤是:

1.将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上

2.在日志文件中写入一个检查点记录

3.将当前数据缓冲区的所有数据记录写入磁盘的数据库中

4.把检查点记录在日志文件中的地址写入一个重新开始文件

 

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

当事务T在一个检查点之前提交:

  1. T对数据库所做的修改一定都已写入数据库
  2. 写入时间是在这个检查点建立之前或在这个检查点建立之时
  3. 在进行恢复处理时,没有必要对事务T执行REDO操作

使用检查点的恢复步骤

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

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

  • 建立两个事务队列
    • UNDO-LIST
    • REDO-LIST
    • ACTIVE-LIST暂时放入UNDO-LIST队列,REDO队列暂为空

 3.从检查点开始正向扫描日志文件,直到日志文件结束

  • 如有新开始的事务Ti,把Ti暂时放入UNDO-LIST队列
  • 如有提交的事务Tj,把TjUNDO-LIST队列移到REDO-LIST队列

4.UNDO-LIST中的每个事务执行UNDO操作

                  REDO-LIST中的每个事务执行REDO操作

 

镜像

 

为避免硬盘介质出现故障影响数据库的可用性,许多DBMS提供了数据库映像(mirror)功能用于数据库恢复。

将整个数据库或其中的关键数据复制到另一个磁盘上,每当主数据库更新时,DBMS自动把更新后的数据复制过去,由DBMS自动保证镜像数据与主数据库的一致性。一旦出现介质故障,可由镜像磁盘继续提供使用,同时DBMS自动利用磁盘数据进行数据库的恢复,不需要关闭系统和重装数据库副本。

在没有出现故障时,数据库镜像还可以用于并发操作,即当一个用户对数据库加排它锁修改数据时,其他用户可以读镜像数据库上的数据,而不必等待该用户释放锁。

由于数据库镜像是通过复制数据实现的,频繁地赋值数据自然会降低系统运行效率。因此在实际应用中用户往往只选择对关键数据和日志文件进行镜像。

 

 

 

小结:

 

  • 如果数据库只包含成功事务提交的结果,就说数据库处于一致性状态。保证数据一致性是对数据库的最基本的要求。
  • 事务是数据库的逻辑工作单位
    1. DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性
  • DBMS必须对事务故障、系统故障和介质故障进行恢复
  • 恢复中最经常使用的技术:数据库转储和登记日志文件
  • 恢复的基本原理:利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库

常用恢复技术

 

事务故障的恢复

  • UNDO

系统故障的恢复

  • UNDO + REDO

介质故障的恢复

  • 重装备份并恢复到一致性状态 + REDO

 

提高恢复效率的技术

检查点技术

  • 可以提高系统故障的恢复效率  
  • 可以在一定程度上提高利用动态转储备份进行介质故障恢复的效率

镜像技术

  • 镜像技术可以改善介质故障的恢复效率

 

 

文章来源: fantianzuo.blog.csdn.net,作者:兔老大RabbitMQ,版权归原作者所有,如需转载,请联系作者。

原文链接:fantianzuo.blog.csdn.net/article/details/103324181

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。