故障管理

Posted 2022-12-12 修罗神天道

任何一个数据库应用系统，特别是重要的应用系统，如果数据库发生故障导致数据遭到破坏或损坏，将带来巨大的甚至是灾难性损失。因此，如何从故障中恢复数据库,保证数据库中数据的安全性和正确性是一个至关重要的问题。本章将就数据库故障的恢复技术作比较详细的论述。 
本章首先介绍数据库恢复的一般步骤 ，然后结合数据库中常见的四种故障,介绍每种故障的解决策
略,之后介绍数据库恢复技术中最常用的几种恢复技术如数据转储技术、登记日志文件技术、数据库镜像技术和廉价冗余磁盘阵列(RAID)的恢复策略。 

11.1故障管理概述 

11.1.1故障类型及其解决方法 
在数据库系统中大致存在四类故障，即事务内部的故障、系统故障、介质故障以及计算机病毒故障。
每种故障需要不同的方法来处理。 
1.事务内部的故障 
事务内部故障分为预期的和非预期的，其中大部分是非预期的。 
(1)预期的事务内部故障。 
预期的事务内部故障是指可以通过事务程序本身发现的事物内部故障。如果发生了预期的事务内部故障，可以通过将事务回滚撤销其对数据库的修改，从而使数据库回到一致性的状态。 
(2)非预期的事务内部故障。 
非预期的事务内部故障是不能由事务程序处理的，如运算溢出故障、并发事务死锁故障、违反了某此完整性限制而导致的故障等。由于事务内部的故障大部分属于此类，所以以后的事务故障仅指这类故障。 
事务故障表明事务没有提交或撤销就结束了,因此数据库可能处于不准确状态。所以,恢复程序必须强行回滚事务,在保证该事务对其他事务没有影响的条件下，利用日志文件撤销其对数据库的修改,使数据库恢复到该事务运行之前的状态。 
事务故障的恢复是由系统自动完成的，对用户是透明的。 
2.系统故障 
系统故障又称软故障态。是指数据库在运行过程中，由于硬件故障、数据库软件及操作系统的漏洞，突然停电等情况，导致系统停止运转，所有正在运行的事务以非正常方式终止,需要系统重新启动的一类故障。这类故障影响正在运行的所有事务。 
要消除这些事务对数据库的影响，保证数据库中数据的一致性。办法是在计算机系统重新启动后,对于未完成的事务可能已经写入数据库的内容，回滚所有未完成的事务写的结果，以保证数据库中数据的一致性；对于已完成的事务可能部分成全部留在缓冲区的结果，需要重做所有已提交的事务,以将数据库真正恢复到一致状态。 
当数据库发生系统故障时，容错对策是在重新启动系统后，撤销（UNDO)所有未提交的事务，重做( REDO)所有已提交的事务，以达到容错目的。 
3.介质故障 
介质故障又称硬故障，主要指数据库在运行过程中，由于磁头碰撞、磁盘损坏、强磁干扰、天灾人祸等情况,使得数据库中的数据部分或全部丢失的一类故障。 
介质故障的容错对策采用两种方式。 
（1）软件容错 
使用数据库备份及事务日志文件，通过恢复技术，恢复数据库到备份结東时的状态。如果介质故障真的导致数据库物理存储设备损坏，事务日志文件丢失，采用这种方式几乎不能达到数据库的完全恢复，只能恢复到备份数据库后的某个时间点。对于重要的数据，软件容错有其局限性。 
（2）硬件容错 
采用硬件容错方法保证在介质故障下的数据库能够完全恢复。硬件容错目前常用的方法是采用双物理存储设备，如双硬盘镜像，使两个硬盘存储内容相同，当一个硬盘出现介质故障时，另一个硬盘中的数据没有被破坏，从而达到数据库完全恢复的效果。这种方式有一个缺点，即如果出现较严重的自然灾害或机房环境出现火灾、水灾等情况,导致双硬盘同时损坏,则失去保护作用。 
4.计算机病毒故障 
计算机病毒是一种恶意的计算机程序,它可以像病毒一样繁殖和传播,在对计算机系统造成破坏的同
时也可能对数据库系统造成破坏(破坏方式以破坏数据库文件为主)。 
只能使用数据库备份文件，以软件容错的方式恢复数据库文件，达到数据库正常工作状态。 
这四类故障虽然各有不同，但其对数据库的影响无外乎两种可能，即对数据库本身的破坏或是对数据库中数据的破坏。其恢复的基本原理概括起来也只有两个字,即冗余。这就是说,数据库中所有数据都可以根据存储在别处的冗余数据来重建。 
11.1.2数据库恢复技术概述 
数据库系统必须具备如下功能，即在故障发生时，能够利用存储在系统其他地方的冗余数据来重建数据库中被破坏的或不正确的数据，把数据库从错误状态恢复到某一已知的正确状态,从而重新建立一个完整的数据库，这就是数据库恢复。 
恢复机制涉及的两个关键问题是:第一，如何建立冗余数据;第二，如何利用这些冗余数据实施数据库恢复。 
建立冗余数据的技术有很多，例如为数据备份、登记日志文件数据库复制、数据库镜像、为段设立保存点以及使用后备段与现行页表来支持对段的保存等。但其中最常用的还是数据备份和登录日志文件,在一个数据库系统中,这两种技术通常是结合起来使用的。 

11.2数据转储 

数据转储是指数据库管理员(DBA)或数据库管理系统定期复制数据库，并将复制得到的数据存放到其他介质中的过程，数据转储也称为数据备份。这些保存在其他介质上的副本常被称为后援副本或后备副本。
数据库管理员可以在数据库系统发生故障后，利用这些副本恢复数据库。 
但要注意的是，此时数据库只能恢复到转储时的状态，要想恢复到故障之前的状态，需要参考日志文件,重新运行转储后到故障前的所有事务才可以。 
1.静态转储和动态转储 
(1)静态转储。 
在静态转储过程中系统不能运行其他事务，不允许在转储期间对数据库有任何的存取、修改活动，即转储前后系统必须处于一个一致性的状态。 
静态转储虽然很简单，但是转储操作必须等待旧事务的结束，而新事务也必须等待转储操作的完成，转储操作和事务是互斥的，一个时间段内要么转储要么运行事务，因此会降低数据库的可用性。为了克服这个缺点出现了动态转储。 
(2)动态转储。 
动态转储是指允许转储操作和用户事务并发执行，即允许在转储过程中对数据库进行存取和修改操作。
动态转储中可能存在事务对数据库中的数据进行修改操作,因此并不能保证转储数据的一致性。因为转储文件只保存了转储期间某一刻的数据，若下一时刻事务修改该数据，这个变动的数据并不会反映在转储文件上。也就是说,在转储结束后,转储文件上的数据并非是某个时间点的数据，而可能是多个时间点的混合数据。 
综上所述，静态转储虽然保证了数据的有效性，但是却是以降低数据库的可用性为代价的;而动态转储虽然提高了数据库的可用性，但数据的有效性却可能得不到保证。 
引入日志文件用它记录转储期间各事务对数据库的修改活动记录,然后使用动态转储的备份副本加上日志文件就可以将数据库恢复到某一时刻的正确状态。 
2.数据转储机制 
(1)完全转储。 
完全转储是对数据库中所有数据进行转储。这种转储方式需占用较多的时间和空间，但在系统失败时恢复时间短。 
(2)增量转储。 
只复制上次转储后发生变化的文件或数据块。增量转储所需的时间和空间都比较短，但增量转储数据只能和完全转储配合，才能对数据库进行恢复。增量转储恢复时间比仅使用完全转储要长。 
(3)差量转储。 
对最近一次数据库完全转储以来发生的数据变化进行转储，差量转储也称差异转储。它和完全转储相比速度快，占用较小的空间；和增量转储相比，速度慢占用空间多，恢复速度比增量转储快。 
完全转储、增量转储和差量转储 3 中数据转储机制的特点进行了比较，如下表所示。  
3.多种转储方法结合使用 
(1)仅使用完全转储。 
仅使用完全转储会产生大量数据移动占用时间和空间较多,对数据库性能可能产生较大影响,这种方
法代价比较大。 
(2)完全转储加增量转储。 
完全转储加增量转储是每隔段时间进行一次完全转储,在完全转储中间执行多次增量转储,这样避免
了全部使用完全转储所导致的大量数据移动。在这种转储方式下,恢复中使用的转储文件较多，其中任何一次转储出了问题都会导致恢复的失败,同时恢复时间较长。 
(3)完全转储加差量转储。 
由于完全加增量方法中数据恢复很困难，所以有了完全转储加差量转储方法。尽管差量转储比增量转储移动和存储更多的数据,但恢复操作简单,恢复时间也较短。 

11.3日志文件 

11.3.1 日志文件的概念 
日志文件记录每个事务对数据库的修改操作。数据库系统在运行过程中,将所有事务的修改操作登记到日志文件中。 
日志文件的具体作用为: 
1.事务故障恢复和系统故障恢复必须使用日志文件 
(1)故障恢复的两个基本操作。 
利用日志文件进行故障恢复时有两个基本操作:UNDO(Ti)和 REDO(Ti)。 
UNDO(Ti)的作用是撤销事务 Ti,其具体步骤为: 
①反向扫描日志文件,找到需要撤销的事务的更新操作。 
②对事务 Ti 的更新操作执行逆操作，即将日志文件中“更新前的值”写入数据库。如果日志记录中
是插入操作,撤销时就做删除操作;如果日志记录中是删除操作，撤销时就做插入操作;如果日志记录中是修改操作，撤销时就用修改前的值代替修改后的值; 
③继续反向查找该事务的其他更新操作，并执行相应的逆操作。 
④重复执行步骤③，直至遇到该事务的开始记录。 
REDO(Ti)的作用是重做事务 Ti,其具体步骤为: 
①正向扫描日志文件，找到需要重做的事务的更新操作。 
②对事务 Ti 重新执行日志文件登记的操作，即将日志文件中“更新后的值"写入数据库。 
③继续正向查找该事务的其他更新操作,并重新执行,将日志文件中“更新后的值"写入数据库。 
④重复执行步骤③，直至遇到该事务的提交记录。 
(2)事务故障恢复。 
事务是一个完整的工作单元，事务中的操作要么全做，要么全不做，否则数据库会出现不一致的状态,因此事务故障恢复时只需把相应的事务作撤销操作 UNDO(Ti)即可。 
(3)系统故障恢复。 
系统故障恢复比事务故障恢复稍显复杂,这些事务中,分两种情况讨论。 
①有些事务已经开始但是还没有提交，即在日志文件中有开始记录 BEGIN TRANSACTION,而没有结束记录，即没有 COMMIT 或者 ROLLBACK,处理这种事务的方法是使其撤销。 
②事务已经完成了事务的所有操作并提交，但其对数据库的修改还保留在缓冲区中,没有写到数据库中,其表现是在日志文件中既有 BEGIN TRANSACTION 记录，又有 COMMIT 记录,对于这种情况，这些事务应该重做。 
具体步骤如下: 
①正向扫描日志文件,找到系统故障前发生的所有事务，如果该事务没有完成，将其事务标记加入撤销队列；如果该事务已经完成，则将其事务标记加入重做队列。 
②对撤销队列中的所有事务作撤销操作 UNDO。 
③对重做队列中的所有事务作重做操作 REDO。 
2.在动态转储方式中必须建立日志文件 
在动态转储中,利用转储文件只能将数据库恢复到转储过程中的某个状态，且转储文件中的数据可能处于不一致状态，只有和日志文件综合起来使用，才能将数据库恢复一致状态，或将数据库恢复到故障发生前的状态，从而直效地恢复数据库。 
3.在静态转储方式中，也可以使用日志文件 
在静态转储方式中，当数据库毁坏后可使用转储文件把数据库恢复到转储结束时刻的状态，然后利用日志文件,把已经完成的事务进行重做处理，对故障发生时尚未完成的事务进行撒销处理。这样不必重新运行已完成的事务程序就可以把数据库恢复到故障前某一时刻的正确状态。 
11.3.2日志文件的格式与内容 
不同的数据库系统采用的日志文件格式并不完全一样,但概括起来日志文件主要有两种格式:以记录
为单位的日志文件和以数据块为单位的日志文件。 
1.以记录为单位的日志文件 
以记录为单位的日志文件内容包括每个事务的开始标记(BEGIN TRANSACTION)、每个事务的结束标记(包括事务提交记录或事务终止记录)，以及每个事务的所有修改操作(位于开始标记和结束标记之间)。 
2.以数据块为单位的日志文件 
这种机利将更新前的整个块和更新后的整个块都放在了日志文件中。所以，日志记录的内容只需包括事务标识和被更新的数据块;而不需要包括操作类型和操作对象等信息。

11.3.3登记日志文件的原则 
为保证数据库是可恢复的，登记日志文件必须遵循两条原则： 
①登记的次序严格按并行事务执行的时间次序。 
②必须先写日志文件，后写数据库。 
第一条原则表现了事务对数据库操作的可再现性和正确性。 
第二条原则的规定也是必然的。因为把事务登记到日志文件和把事务对数据的修改写到数据库是两个不同的过程.必然存在先后顺序。 
11.3.4检查点 
1.检查点的作用 
在利用日志文件恢复数据库数据的过程中，恢复子系统需要搜索日志，检查所有日志记录，把故障发生时没有提交的事务撤销，把已经提交的事务重做。检查点最大限度地减少了数据库完全恢复时所必须执行的日志部分，改善恢复效率。 
2.检查点的引入 
检查点的引入是在日志文件中增加一类新的记录——检查点记录，增加一个“重新开始文件”（用来
记录各个检查点记录在日志文件中的地址），并让恢复子系统在登录日志文件期间动态的维护日志。检查点记录内容如下： 
①建立检查点时刻所有正在执行的事务清单。 
②这些事务最近一个日志记录的地址。 
动态维护日志文件的方法是周期性地执行如下操作:建立检查点,保存数据库状态。具体步骤是： 
①将当前日志缓冲中的所有日志记录写入磁盘的日志文件上； 
②在日志文件中写入一个检查点记录； 
③将当前数据缓中的所有数据记录写入磁盘的数据库中； 
④把检查点记录在日志文件中的地址写入一个“重新开始文件”。 
恢复子系统可以定期或不定期地建立检查点来保存数据库状态。检查点可以按照预定的一个时间间隔建立。 
3.基于检查点的恢复步骤 
系统使用检查点的方法进行恢复的步骤是: 
(1)从“重新开始文件”中找到最后一个检查点记录在日志文件中的地址由该地址在日志文件中找到
最后一个检查点记录。 
(2)由该检查点记录得到检查点建立时刻所有正在执行的事务清单 ACTIVE-LIST。 
这里要建立两个事务队列: 
①UNDO-LIST:需要执行 UNDO 操作的事务集合。 
②REDO-LIST:需要执行 REDO 操作的事务集合。 
把 ACTIVE-LIST 暂时放入 UND0 LIST 队列,REDO 队列暂为空。 
(3)从检查点开始正向扫描日志文件。 
①如有新开始的事务 Ti,把 iT 暂时放入 UNDO-LIST 队列。 
②如有提交的事务 Tj，把 Tj 从 UNDO-LIST 队列移到 REDO-LIST 队列。 
直到日志文件结束。 
(4)对 UNDO-LIST 中每个事务执行 UNDO 操作,对 REDO-LIST 中的每个事务执行 REDO 操作。

11.4硬件容错方案 

11.4.1 概述 
为了保证数据库系统的连续运行，仅仅依靠数据库系统软件不能满足要求。因此需要从硬件级别从数据库系统进行保护。 
硬件容错的方案需要从数据库系统运行所需要的各种环境出发，分析支撑数据库系统运行的环节。例如机房的电力、机房空调环境、网络、存储、服务器、综合考虑，否则某一个环节出现故障都可能导致数据库系统不可运行。 
11.4.2磁盘保护技术 
（1）RAID 系统 
描述：廉价冗余磁盘阵列（RAID），它是由多块磁盘构成的一个整体，但这并不等于是简单的磁盘容量叠加，而是相对于其他存储设备在容量、管理、性能、可靠性和可用性上都有了进一步提高。 
特点：当从这些磁盘中抽出一块来，利用其他磁盘上的信息，可以恢复出这块磁盘的信息。 
RAID 系统可以连接在主机系统上，作为存储数据的介质，具有设备虚拟化的能力。RAID 子系统图如下所示。 
 
（2）RAID 的两个冗余技术 
①镜像冗余 
镜像冗余就是把所有的数据复制到其他的设备上或其他地方。 
特点：实现起来很简单，但是额外开销很大，需要更多的磁盘、控制器和电缆。 
②校验冗余 
检验冗余就是通过对成员磁盘上的数据执行异或(XOR)操作，得到其校验值，并存放在另外的校验磁盘上。 
特点：实现起来很复杂，但是它占用的磁盘比镜像冗余少。 
（3）常见的 RAID 级别和特点如下所示。 
①RAID0： 
优点：采用数据分块并行传送方式，能够提高读写速度。 
缺点：RAID 中存储空间没有冗余，对系统的可靠性没有提高，任一个硬盘介质出现故障时，数据将无法恢复。 
②RAID1： 
优点：提高了读速度，加强了系统的可靠性。 
缺点：硬盘的利用率低，冗余度为 50%，同时写速度并未提高。 
③RAID5： 
RAID5 可为系统提供数据安全保障，保障程度比 RAID1 低；而磁盘空间利用率比 RAID1 高，存储成本相对较低。RAID5 有和 RAID0 相近似的数据读取速度。 
④RAID10： 
RAID10 是一个 RAID0 与 RAID1 的组合体，它继承了 RAID0 的快速的 RAID1 的安全。RAID10 冗余度为50%，读写速度均提高。 
（4）软 RAID 和硬 RAID 
软 RAID 是由操作系统或操作系统内专用的软件实现的 RAID。 
硬 RAID 是由专用的硬件设备实现的 RAID。在数据库系统的服务器上，一般选择使用硬 RAID,因为硬RAID 一般采用专用的硬件芯片,计算速度快，性能高,维护简单，当磁盘出现故障时可以在不停机的情况下方便更换。同时在高端的硬 RAID 中，一般带有专用的缓存芯片,可以将部分操作数据缓存在 RAID 卡的内存中,以提高读写速度。 
在数据库系统的数据存储中,在成本可以承受的情况下,-般建议采用 RAID10,同时建议采用带有缓存
的硬 RAID。 
11.4.3服务器容错技 
1.引入服务器容错原因 
RAID 技术可以防止磁盘损坏导致数据库系统异常停止工作。 
服务器容错可以防止服务器硬件故障或操作系统软件出现故障造成数据库系统的异常，导致数据库系统不能对外提供服务。 
服务器容错技术就是为了解决服务器硬件异常问题出现的解决方案。 
2.服务器容错技术简介                                        
服务器容错技术一般是采用两台相同的服务器，两台服务器共享存储设备，其中一台服务器运行数据库系统，数据库数据存储在存储设备中。 

 3.服务器接管过程 
在 Active-Standby 工作模式中，公有网络为客户端和数据库服务器连接的网络，私有网络为两台数据库服务器之间检测状态的网络。当运行服务器出现故障时，备用服务器将自身角色转换为运行服务器，接管原有运行服务器的资源，一般情况下需要接管的资源有:共享存储资源、服务器 IP 地址。通过接管服务器 IP 地址，客户端无须进行任何更改即可连接到原有的备用服务器。 
Aetive-Standby 工作模式是最常用的服务器容错技术。此种技术一般和数据库系统无关，数据库系
统无需了解自己运行于什么模式中,因此适用性比较好。不过此种模式的弊端也比较明显，首先是计算资源浪费比较严重，备用服务器在日常工作中处于 Standby 状态。另外,Active-Standby 模式下，运行服务器和备用服务器之间的切换从本质上讲可以认为是数据库重新启动的过程，重新启动过程中，所有数据库连接将会中断,并且重新启动需要一段时间。一般需要几分钟到十几分钟，运行级别较高的系统来说，十几分钟的中断可能是不可接受的。 
4.其他服务器容错技术简介 
①在硬件级别 
一些小型机为了提供硬件级别的高稳定性，采用了自行设计制造的专用软硬件构架。 
例如：当 CPU 或内存出现硬件故障时，如果操作系统内核并未运行在此 CPU 或内存上，操作系统内核可以将任务直接分配到正常的 CPU 或内存上，而后关闭这些 CPU 或内存，保证系统运行稳定。 
②在软件级别 
一些大型的数据库软件提供了专用的服务器级别容错技术。 
例如：Oracle 数据库提供了 RAC 架构。在 Oracle RAC 架构中，数据库可以同时运行在多台服务器上，这些服务器共享一个存储。 
11.4.4数据库镜像与数据库容灾 
1.引入数据库镜像的原因 
随着企业信息化程度的不断加深，企业日常工作对服务的依赖性也在不断增加。因此，企业对数据库服务器的可靠性、稳定性提出了更高的要求。为了避免介质故障对数据库可用性的影响，许多数据库管理系统都提供了数据库镜像功能。 
2.数据库镜像简介 
数据库镜像是一种用于提高数据库可用性的解决方案，它根据 DBA 的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上。不同的磁盘上有不同的数据库服务器，他们通过相应的软硬件技术手段，实现应用和数据的相互备份。 
数据库镜像有许多优点，具体如下： 
①数据库镜像提供完整成接近完整的数据冗余，增强数据保护功能。 
②发生灾难时，数据库镜像可快速使数据库的备用副本提供服务,使数据不会丢失.提高数据库的可用性。 
③提高镜像数据库在升级级期间的可用性。 
3.数据库镜像分类 
数据库镜像的基本架构共分两种模式：双机互备援模式和双机热备份模式。 
(1)双机互备援模式。 
所谓双机互备援就是两台主机均为工作机，在正常情况下，两台工作机均为信息系统提供支持，并互相监视对方的运行情况。当一台主机出现异常时，另一台主机则主动接管异常机的工作,从而保证信息机则系统能够不间断地运行，但正常运行的主机的负载会有所增加。 
工作机切换时机: 
①系统软件或应用软件造成服务器宕机。 
②服务器没有宕机，但系统软件或应用软件工作不正常。                                        
③SCSI 卡损坏,造成服务器与磁盘阵列无法存取数据。 
④服务器内硬件损坏,造成服务器宕机。 
⑤服务器不正常关机。 
(2)双机热备份模式。 
所谓双机热备份就是一台主机为工作机,另一台主机为备份机。在系统正常运行情况下，工作机为信息系统提供支持，备份机监视工作机的运行情况(工作机也同时监视备份机是否正常，有时备份机因某种原因出现异常，工作机会通知系统管理员解决,确保下一次切换的可靠性)。 
双机热备份模式的切换时机与双机互备援模式的切换时机一致。  
4.工作方式  

注意： 
重做通过将每个活动事务日志记录发送到镜像服务器来完成，日志记录按顺序应用到镜像数据库中。每当数据库更新时，DBMS 将自动保证镜像数据库与主数据的一致性。 
在出现介质故障时，可由镜像数据库继续提供使用，同时 DBMS 自动利用镜像磁盘数据进行主数据库的恢复，不需要关闭和重装数据库副本。 
5.SQL Server 数据库镜像简介 
SQL Server 数据库镜像是将数据库事务处理从 SQL Server 数据库移动到不同 SQL Server 环境中的另外一个 SQL Server 数据库中。 
镜像的复制是一个备用的复制，不能直接访问，只用来进行错误恢复。 
数据库镜像会话以同步操作或异步操作运行。 
在异步操作下，事务不需要等待镜像服务器将日志写入磁盘便可提交,这种方式可以最大程度地提高性能。 
在同步操作下，事务将在伙伴双方处提交,但会延长事务滞后时间。 

 有两种镜像运行模式：高安全性模式和运行模式。 
（1）高安全性模式 
⚫  支持同步操作，也就是“高性能模式”。 
⚫  当会话开始时，镜像服务器将使镜像数据库尽快与主体数据库同步。同步数据库之后，事务将在伙伴双方处提交，会延长事务滞后时间。 
数据库镜像提供了 3 种实现方式: 
①高可用性:两台服务器上同步事务写人，并支持自动错误恢复。 
②高保护:两台服务器上同步事物写人，但是错误恢复是手工的。 
                                       
③高性能:两台服务器上的写人可以不同步的.因此在性能上有所提高，只允许手工的错误恢复。