四级数据库_11_灾难

阅读数:2,835 发表于:发布于 由beyond

第11章 故障管理

四级数据库 返回到 『四级数据库』

11．1 事务

1、事务是数据库的逻辑控制单位，是操作数据的一个程序执行单元。

2、为了保证数据的完整性，要求数据库系统维护事务具有如下性质：

  • A 原子性：事务是一个不可分割的工作单位，事务中的操作要么都做，要么都不做；
  • C 一致性：事务执行的结果必须使数据库从一个一致的状态变到另一个一致的状态；
  • I 隔离性：一个事务内部的操作及使用的数据对于其他并发事务是隔离的；
  • D 持续性：一个事务提交后，它对数据库中数据的改变是永久性的，即使系统可能出现故障，也不会对其它执行的结果有任何影响。

11．2 故障的种类（4类）及解决方法（冗余）

11.2.1 事务内部故障

1、预期的事务内部故障：

通过 事务程序 本身发现的事物内部故障，可以通过将事务回滚，撤销其对数据库的修改，从而使数据库回到一致性的状态；

2、非预期的事务内部故障：

（1）由于事务内部故障大部分属于此类，所以事务故障仅限指此类故障；

（2）事务故障  表明  事务没有提交  或  撤销  就结束了，因此数据库可能处于不正确的状态

因此，恢复事务必须强行回滚事务，在保证该事务对其他事务没有影响的条件下，利用日志文件撤销其对数据库的修改，使数据库恢复到该事务运行之前的效果；

（3）事务故障恢复是由系统自动完成的，对用户是透明的。

11.2.2 系统故障（软故障）

1、指数据库在运行过程中，由于硬件故障、数据库软件及操作系统的漏洞、突然停电等情况，导致系统停止运转，所有正在运行的事务以非正常方式终止，需要系统重新启动的一类故障；

2、系统故障导致内存中的内容丢失，而在硬盘上的内容仍然完好；从而导致数据库的数据可以处于不正确的状态；

3、要消除这些事务对数据库的影响，保证数据库中数据的一致性，办法就是在计算机系统重新启动后，

对于未完成的事务  可能  已经写入数据库的内容，回滚  所有未完成的事务  写的结果，以保证数据库中数据的一致性；

对于已完成的事务可能  部分或全部  留在缓存区的结果，需要重做  所有已提交的事务，以将数据库真正恢复到一致状态。

4、一句话，当数据库发生系统故障时，容错对策是在重新启动系统后，

撤销（UNDO）所有未提交的事务，重做（REDO）所有已提交的事务。

11.2.3 介质故障（硬故障）

1、指数据库在运行过程中，由于磁盘损坏、天灾人祸等情况，使用数据库中的数据部分或全部丢失的一类故障；

2、介质故障的容错对策采用两种方式：

（1）软件容错：

是使用数据库备份及事务日志文件，通过恢复技术，恢复数据库到备份结束时的状态；

（2）硬件容错：

目前常用的方法是采用双物理存储设备，最完全的方式是设计两套相同的数据库系统同时工作，数据的变化也同步，空间有一定距离，这样当发生损坏性的自然现象时，由于两套数据库系统具有空间距离，因此同时发生破坏的概率几乎为零，达到数据库的完全安全。

11.2.4 计算机病毒故障

1、计算机病毒是一种恶意的计算机程序，在对计算机系统造成破坏的同时也可对数据库系统造成破坏（主要破坏数据库文件）；

2、可以通过设立防火墙预防，杀毒软件查杀已感染的文件  和  数据库备份来解决；

11．3 数据库恢复技术概述

  • 恢复机制涉及两个关键问题：
    • 如何建立冗余数据；
    • 如何利用这些冗余数据实施数据库恢复。
  • 最常用的建立冗余数据技术是数据备份和登录日志文件，他们通常是结合起来使用的。

11．4 数据转储

  • 数据转储—指数据库管理员（DBA）定期拷贝数据库，并将拷贝得到的数据库放到其他介质中的过程。
  • DBA可在数据库系统发生故障后，利用这些副本恢复数据库，但此时恢复的数据库只能回到转储时的状态，要想恢复到故障前的状态，需要参考日志文件，重新运行转储后到故障前的所有事务才可以；

  • 静态转储和动态转储

    • 静态转储：在静态转储过程中系统不能运行其他事务，不允许在转储期间对数据库的任何存取、修改活动。
    • 动态转储：允许转储操作和用户事务并发执行；

    • 静态转储虽然保证了数据的有效性，但却是以降低数据库的可用性为代价；

    • 而动态转储虽然提高了数据库的可用性，但数据库的有效性却得不到保证。
    • 为了能保证数据的有效性，而又不降低可用性，就需要引入日志文件，用它记录转储期间各事务对数据库的修改活动，然后使用动态转储的备份副本加上日志文件就可将数据库恢复到某一时刻的正确状态。

  • 几种数据转储机制

    • 完全转储：对所有数据库进行备份，需占用较多时间和空间，可作为系统失败时恢复数据库的基础；
    • 增量转储：只复制上次备份后变化的文件；
    • 差量转储：对最近一次数据库完全备份以来发生的数据变化进行备份，优点是速度快，占用较少的时间和空间。

  • 多种转储方法结合使用

    • 仅采用完全转储；
    • 完全转储 + 增量转储；
    • 完全转储 + 差量转储

11．5 登记日志文件

11．5．1 日志文件的格式和内容

日志文件是记录每个事务对数据库更新操作的文件，

数据库系统在运行过程中，DBMS负责将所有事务的更新操作登记到日志文件中，也就是说日志文件是系统自动维护的。

1、以记录为单位的日志文件：

其内容包括每个事务的开始标记、结束标记和所有更新操作；

每个日志记录的内容包括：事务标识、操作类型、操作对象、更新前数据的旧值，和更新后数据的新值；（p188，表11-2）

2、数据块为单位的日志文件：将更新前的整个数据块 和 更新后的整个数据块全部放在了日志文件中；

11．5．2 日志文件的作用

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

（1）故障恢复的两个基本操作：UNDO和REDO

  • UNDO的作用是撤销事务，具体步骤：

    • 反向扫描日志文件，找到需要撤销的事务的更新操作；
    • 对事务的更新操作执行逆操作；
    • 继续反向查找该事务的其他更新操作，并执行相应的逆操作；
    • 重复执行步骤（C），直至遇到该事务开始记录。

  • REDO的作用是重做事务，具体步骤：

    • 正向扫描日志文件，找到需要重做的事务的更新操作；
    • 对事务重新执行日志文件登记的操作，即将日志文件中“更新后的值”写入数据库；
    • 继续正向查找该事务的其他更新操作，并重新执行，将日志文件中“更新后的值”写入数据库；
    • 重复执行步骤（C），直至遇到该事务的提交记录。

  • 事务故障恢复：只需把相应的事务作  撤销UNDO  即可；

  • 系统故障恢复：

  • 1、事务已经开始，但没有提交，也就是日志文件中有begin transaction,但没有commit,此种直接undo；
  • 2、完成所有操作并都提交了，但没有真正写入数据库，也就是日志是完整的，此种不仅undo，还要redo（注意数据是在内存缓冲区修改的）

  • 步骤如下:

    • 正向扫描日志文件，找到系统故障前发生的所有事务，
    • 如果该事务没有完成，将其事务标记加入撤销队列，
    • 如果该事务已经完成，则将其事务标记加入重做队列；
    • 对撤销队列中的所有事务作撤销操作UNDO；
    • 对重做队列中的所有事务作重做操作REDO。

在动态转储方式中必须建立日志文件

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

11．5．3 登记日志文件的原则

  • 登记的次序严格按并行事务执行的时间次序；
  • 必须先写日志文件，后写数据库

11．6 具有检查点的恢复技术

11．6．1 检查点的作用

检查点最大限度地减少数据库完全恢复时所必须执行的日志部分；

11．6．2 检查点的引入

1、在日志文件中增加一类新的记录—检查点记录，增加一个“重新开始文件”，

并让恢复子系统在登录日志文件期间动态地维护日志

2、检查点记录的内容：

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

3、“重新开始文件”用来记录各个检查点在日志文件中的地址；

  • 动态维护日志文件的方法是周期性地执行如下操作：建立检查点、保存数据库状态，

  • 具体步骤：

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

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

  • 使用检查点方法可以改善恢复效率，事务在检查点前已经提交，则不必执行REDO操作。

11．6．3 恢复的步骤

  • 从“重新开始文件”中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录；
  • 由该检查点记录得到检查点建立时刻所正在执行的事务清单(ACTIVE-LIST)，
  • 需要执行UNDO操作的事务建立UNDO-LIST队列，
  • 需要执行REDO操作的事务建立REDO-LIST队列；（把全部ACTIVE-LIST中的全放在放在UNDO-LIST中，REDO-LIST默认为空）
  • 从检查点开始正向扫描日志文件，如有新开始的事务，则放入UNDO队列，如有提交事务，则放入REDO队列；
  • 对UNDO队列中的每个事务执行UNDO操作，对REDO队列中的事务进行REDO操作。

11．7 数据库镜像

11．7．1 数据库镜像的引入

为了避免介质故障对数据库可用性的影响，许多数据库系统都提供了数据库镜像的功能

11．7．2 数据库镜像简介

  • 数据库镜像是一种用于提高数据库可用性的解决方案，它根据DBA要求，自动把整个数据库或其中的关键数据复制到另一个磁盘中。

  • 数据库镜像的优点：（不同磁盘上有不同服务器，它们相互侦查，出问题时，好的主动接管出问题的服务器）

    • 数据库镜像提供完整或接近完整的数据冗余，增强数据保护功能；
    • 发生灾难时，数据库镜像可快速使数据库的备用副本提供服务，使数据不会丢失，提高数据库的可用性；
    • 提高镜像数据库在升级期间的可用性。

11．7．3 数据库镜像分类

  • 双机互备援模式：就是两台主机均为工作机，两台工作机均为信息系统提供支持，并互相监视对方的运行情况，
  • 当一台主机出现异常时，另一主机则主动接管异常机的工作，保证信息系统能够不间断运行。

  • 工作机的切换时机：

    • 系统软件或应用软件造成服务器宕机；
    • 服务器没有宕机，系统软件或应用软件工作不正常；
    • SCSI卡损坏，造成服务器与磁盘阵列无法存取数据；(Small Computer System Interface 小型计算机系统接口)
    • 服务器内硬件损坏，造成服务器宕机；
    • 服务器不正常关机

2、双机热备份模式：一台主机为工作机，另一台主机为备份机，

在系统正常运行的情况下，工作机为信息系统提供支持，备份机监视工作机的运行情况。

当工作机异常时，备份机主动接管工作机工作，从而保证信息系统不间断提供服务。

11．7．4 工作方式

  • 在“数据库镜像会话”中，主体服务器 和 镜像服务器 作为“伙伴”进行通信和协作。
  • 这两个伙伴在会话中扮演互补的角色：“主体角色”和“镜像角色”，
  • 拥有主体角色的称为“主体服务器”，拥有镜像角色的称为“镜像服务器”。

  • 数据库镜像涉及尽快将对主体数据库执行的每项插入、更新和删除操作重做到镜像数据库中。

  • 重做通过将每个活动事务 日志记录发送到镜像服务器来完成，这会尽快将日志记录按顺序应用到镜像数据库中，这样，每当数据库更新时，DBMS将自动保证镜像数据与主体数据的一致性；

  • 在主体服务器出现介质故障时，可由镜像数据库继续提供使用，

  • 同时DBMS将自动利用镜像磁盘数据进行主数据库的恢复，不需关闭系统。

  • 一旦出现介质故障，通常使用一个“角色切换”的过程来互换主体服务器和镜像服务器。

  • 由于数据库镜像是通过复制数据实现的，在实际应用中，用户只选择对关键数据和日志文件进行镜像，而不是对整个数据库进行镜像。

11．8 RAID的恢复技术

磁盘阵列（Redundant Arrays of Independent Drives，RAID）

  • RAID—-廉价冗余磁盘阵列，它是由多块磁盘构成的一个整体，但并不是简单的磁盘容量叠加，而是相对于其他存储设备在容量、管理、性能、可靠性和可用性上都有了进一步的提高。
  • 尤其神奇之处在于: 当从这些磁盘中抽出一块，利用其他磁盘上的信息，可以恢复出这块磁盘的信息；

  • RAID系统可以连接在主机系统上，作为其存储数据的介质，

  • 与一般存储设备不同的是，它具有设备虚拟化的能力。
  • 即RAID系统内部可以包含很多个磁盘驱动器，但在主机系统是看不到的，
  • 主机系统只能通过一个子系统RAID控制器与这些磁盘构成虚拟设备进行交互。

  • RAID的冗余技术：

    • 镜像冗余：把所有的数据拷贝到其他设备上，但额外开销很大，需要更多磁盘、控制器和电缆；

校验冗余：通过对成员磁盘的数据执行异或（XOR）操作，得到其校验值，并存放在另外的校验磁盘上。

该技术实现起来稍显复杂，但它占用的磁盘 比 镜像 少。