数据库的恢复

admin管理员组

文章数量:1532505

2023年12月11日发(作者：)

浅谈企业网数据库故障的恢复

数据库在企业网站的建设中是必不可少的，数据库具有数据结构化，数 据独立性，易于编制程序等优点，在数据库中，尽管我们采取了各种保护措施 来防止数据库的安全性和完整性被破坏，但计算机系统中硬件的故障，软件的 错误，操作员的失误以及恶意破坏等现象仍是不可避免的。这些故障轻则造成 运行事务非正常中断，重则破坏数据库，使数据全部或部分丢失。

企业网的数据库中可能发生的故障大概有这样几种：

事务内部的故障

事务内部故障可分为预期的和非预期的，其中大部分的故障都是非预期 的。预期的事务内部故障是指可以通过事务程序本身发现的事务内部故障；非 预期的事务内部故障是不能由事务程序处理的，如运算溢出故障、并发事务发 生死锁故障、违反了某些完整性限制而导致的故障等。事务故障仅仅指这类非 预期的故障。

事务内部故障意味着事务运行没有达到预期的终点，未能成功地提交事 务，使数据库处于不正确状态。事务内部故障有的可以通过事务程序本身发 现，是可预期的故障，但更多的是不可预期的故障，此时，数据库可能出于不 正确的状态。恢复程序要在不影其他任何事务运行情况下，强行回滚该事务， 即撤销该事务已经做出的任何对数据库的修改，使得该事务好像根本没有启动 一样，这类操作叫做事务撤销。

系统故障

系统故障也称为软故障，是指数据库在运行过程中，由于硬件故障、数据 库软件及操作系统的漏洞、突然停电灯情况，导致系统停止运转，所有正在运 行的事务以非正常方式终止，需要系统重新启动的一类故障。这类事务不破坏 数据库，但是影响正在运行的所有事务。这时数据库缓冲区中的内容都丢失， 所有运行事务都非正常终止。

在发生系统故障时候，有些已经完成的事务可能有一部分或许会全部留在 缓冲区，尚未写到磁盘上的物理数据库中，系统故障使得这些事务对数据库的 修改部分或者全部丢失，因此应将这些事务已提交的结果重新写入数据库中。 介质故障

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

计算机病毒

计算机病毒故障是一种恶意的，人为的故障活破坏，它可以像病毒一样繁 殖和传播，在对计算机系统造成破坏的同时也可能对数据库系统造成破坏。病 毒的种类有很多，不同病毒有不同的特征，小一点的病毒或者只有 20 条指令， 大的计算机病毒像一个操作系统一样有成千上万条指令组成。病毒传播的速度 很快，一旦侵入，马上就会摧毁整个系统，有的病毒还有好长的潜伏期，感染 后数月才发作。

计算机病毒已经成为计算机系统的主要威胁，也是数据库系统的主要威 胁，为此，计算机的工作者已经研制出了许多预防病毒的方法，通过检查，诊 断，消灭计算机中的病毒软件，但是还没有一种软件可以让计算机终身免疫， 因此数据库也不能避免中毒。

总结数据库的各种故障，对数据库的影响有两种：一是数据库本身被破 坏，二是数据库没有被破坏，但是数据可能不正确，这是由于事务的运行被非 正常终止造成的。数据库的恢复原理就是：冗余。也就是说，数据库中任何一 部分被破坏的或不正确的数据可以根据存储在数据库中别处的冗余数据来重 建。原理虽然简单，但是现实操作技术细节却十分的复杂，下面就具体谈论一 下数据库的恢复技术。

建立冗余数据最常用的两种技术是数据转储和登录日志文件，在同一个数 据库中，这两种方法通常是一起使用的

数据转储是数据库恢复中采用的基本技术，所谓转储即 DBA 定期地将整个 数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为 后备副本或后援副本。当数据库遭到破坏后可以将后备副本重新装入将数据库 恢复到转储时的状态再重新运行自转储以后的所有更新事务就可把数据库恢复 到故障发生前的一致状态。转储是十分耗费时间和资源的不能频繁进行。 DBA 应该根据数据库使用情况确定一个适当的转储周期。

转储可分为静态转储和动态转储。静态转储是在系统中无运行事务时进行 的转储操作。即转储操作开始的时刻数据库处于一致性状态而转储期间不允许 或不存在对数据库的任何存取、修改活动。显然静态转储得到的一定是一个数 据一致性的副本。静态转储简单但转储必须等待正运行的用户事务结束才能进 行同样新的事务必须等待转储结束才能执行。显然这会降低数据库的可用性。 动态转储是指转储期间允许对数据库进行存取或修改。即转储和用户事务可以 并发执行。动态转储可克服静态转储的缺点它不用等待正在运行的用户事务结 束也不会影响新事务的运行。但是转储结束时后援副本上的数据并不能保证正 确有效。为此必须把转储期间各事务对数据库的修改活动登记下来建立日志文 件。这样后援副本加上日志文件就能把数据库恢复到某一时刻的正确状态。

转储还可以分为海量转储和增量转储两种方式。海量转储是指每次转储全 部数据库。增量转储则指每次只转储上一次转储后更新过的数据。从恢复角度 看使用海量转储得到的后备副本进行恢复一般说来会更方便些。但如果数据库 很大事务处理又十分频繁则增量转储方式更实用更有效。

登记日志文件，日志文件的格式和内容日志文件是用来记录事务对数据库 的更新操作的文件。不同数据库系统采用的日志文件格式并不完全一样。概括 起来日志文件主要有两种格式以记录为单位的日志文件和以数据块为单位的日 志文件。每个日志记录的内容主要包括事务标识标明是哪个事务操作的类型插 入、删除或修改操作对象记录内部标识更新前数据的旧值对插入操作而言此项 为空值更新后数据的新值对删除操作而言此项为空值。

日志文件的作用是事务故障恢复和系统故障恢复必须用日志文件；在动态 转储方式中必须建立日志文件后援副本和日志文件综合起来才能有效地恢复数 据库；在静态转储方式中也可以建立日志文件。

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

登记日志文件时为保证数据库是可恢复的登记日志文件，必须遵循两条原 则：第一，登记的次序严格按并发事务执行的时间次序。第二，必须先写日志 文件后写数据库。把对数据的修改写到数据库中和把表示这个修改的日志记录 写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障即这两 个写操作只完成了一个。如果先写了数据库修改而在运行记录中没有登记这个 修改则以后就无法恢复这个修改了。

针对不同的故障，我们所采用的恢复策略也不同。

事务故障的恢复

事务故障是指事务在运行至正常终止点前被中止，这时恢复子系统应利用 日志文件撤消（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由 系统自动完成的，对用户是透明的。系统的恢复步骤是：

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

2. 对该事务的更新操作执行逆操作。即将日志记录中 “更新前的值 ”写入数 据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时 “更新前的 值”为空）。若记录中是删除操作，则做插入操作，若是修改操作，则相当于用 修改前值代替修改后值。

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

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

系统故障的恢复

1. 正向扫描日志文件，找出故障发生前已经提交的事务，将其事务标识记 入重（REDO）队列，同时找出故障发生时尚未完成的事务，将其事务标识记入 撤消（UNDO）队列。

2. 对撤消队列中的各个事务进行撤消（UNDO）处理。

3. 对重做队列中的各事务进行重做（REDO）处理。

介质故障的恢复

1.装入最近的数据库后备副本，即故障前最后一次转储的数据库副本。使 数据库恢复到最后转储时的一致性状态。

2•打开永恒存储器中的日志文件，正向扫描日志文件，找出故障发生时已 经提交的事务的标识，将其记入重做队列。然后对重做队列中的所有事务进行 重做。

以上简单介绍了企业网中数据库的几种故障恢复技术，日志恢复技术可以 尽可能地减少日志数量，避免了传统的恢复技术存在的过多的不必要的日志缺 点，恢复技术是保证内存数据库运行可靠的关键技术。然而，企业网中数据库 恢复是一个十分复杂而庞大的技术，所以本文介绍的方法还有待完善。

本文标签： 数据库事务转储故障日志