数据库第13章 数据库恢复技术
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
第13章数据库恢复技术
计算机同其他任何设备一样,都有可能发生故障。故障的原因有多种多样,包括磁盘故障、电源故障、软件故障、灾害故障、人为破坏等。这些情况一旦发生,就有可能造成数据的丢失。因此,数据库管理系统必须采取必要的措施,以保证即使发生故障,也不会造成数据丢失,或尽可能减少数据的丢失。
数据库恢复作为数据库管理系统必须提供的一种功能,保证了数据库的可靠性,并保证在故障发生时,数据库总是处于一致的状态。这里的可靠性指的是数据库管理系统对各种故障的适应能力,也就是从故障中进行恢复的能力。
本章讨论各种故障的类型以及针对不同类型的故障采用的数据库恢复技术。
13.1恢复的基本概念
数据库恢复是指当数据库发生故障时,将数据库恢复到正确(一致性)状态的过程。换句话说,它是将数据库恢复到发生系统故障之前最近的一致性状态的过程。故障可能是软、硬件错误引起的系统崩溃,例如存储介质故障,或者是数据库访问程序的逻辑错误等应用软件错误。恢复是将数据库从一个给定状态(通常是不一致的)恢复到先前的一致性状态。
数据库恢复是基于事务的原子性特性。事务是一个完整的工作单元,它所包含的操作必须都被应用,并且产生一个一致的数据库状态。如果因为某种原因,事务中的某个操作不能执行,则必须终止该事务并回滚(撤销)其对数据库的所有修改。因此,事务恢复是在事务终止前撤销事务对数据库的所有修改。
数据库恢复过程通常遵循一个可预测的方案。首先它确定所需恢复的类型和程度。如果整个数据库都需要恢复到一致性状态,则将使用最近的一次处于一致性状态的数据库的备份进行恢复。通过使用事务日志信息,向前回滚备份以恢复所有的后续事务。如果数据库需要恢复,但数据库已提交的部分仍然不稳定,则恢复过程将通过事务日志撤销所有未提交的事务。
恢复机制有两个关键的问题:第一,如何建立备份数据;第二,如何利用备份数据进行恢复。
数据转储(也称为数据库备份)是数据库恢复中采用的基本技术。所谓转储就是数据库管理员定期地将整个数据库复制到辅助存储设备上,比如磁带、磁盘。当数据库遭到破坏后可以利用转储的数据库进行恢复,但这种方法只能将数据库恢复到转储时的状态。如果想恢复到故障发生时的状态,则必须利用转储之后的事务日志,并重新执行日志中的事务。
转储是一项非常耗费资源的活动,因此不能频繁地进行。数据库管理员应该根据实际情况制定合适的转储周期。
转储可分为静态转储和动态转储两种。
静态转储是在系统中无运行事务时进行转储操作。即在转储操作开始时数据库处于一致性状态,而在转储期间不允许对数据库进行任何操作。因此,静态转储得到的一定是数据库的一个一致性副本。
静态转储实现起来比较简单,但转储必须要等到正在运行的所有事务结束才能开始,而且在转储时也不允许有新的事务运行,因此,这种转储方式会降低数据库的可用性。
动态转储是不用等待正在运行的事务结束就可以进行,而且在转储过程中也允许运行新的事务,因此转储过程中不会降低数据库的可用性。但不能保证转储结束后的数据库副本是正确的,例如,假设在转储期间把数据A=100转储到了磁带上,而在转储的过程中,有另一个事务将A改为了200,如果对更改后的A值没有再进行转储,则数据库转储结束后,数据库副本上的A就是过时的数据了。因此,必须把转储期间各事务对数据库的修改操作记录下来,这个保存事务对数据库的修改操作的文件就称为事务日志文件(log file)。这样就可以利用数据库的备份和日志文件把数据库恢复到某个一致性状态。
转储还可以分为海量转储和增量转储两种。海量转储是指每次转储全部数据库,增量转储是指每次只转储上一次转储之后修改过的数据。从恢复的角度看,使用海量转储得到的数据库副本进行恢复一般会比较方便,但如果数据量很大,事务处理又比较频繁,则增量转储方式会更有效。
海量转储和增量转储可以是动态的,也可以是静态的。
13.2 数据库故障的种类
数据库故障是指导致数据库值出现错误描述状态的情况,影响数据库运行的故障有很多种,有些故障仅影响内存,而有些还影响辅存。数据库系统中可能发生的故障种类很多,大致可以分为如下几类:
1.事务内部的故障
事务内部的故障有些是可以预期到的,这样的故障可以通过事务程序本身发现。如,在银行转账事务中,当把一笔金额从A账户转给B账户时,如果A账户中的金额不足,则应该不能进行转账,否则可以进行转账。这个对金额的判断就可以在事务的程序代码中进行判断。如果发现不能转账的情况,对事务进行回滚即可。这种事务内部的故障就是可预期的。
但事务内部的故障有很多是非预期性的,这样的故障就不能由应用程序来处理。如运算溢出或因并发事务死锁而被撤销的事务等。我们后边所讨论的事务故障均指这类非预期性的故障。
事务故障意味着事务没有达到预期的终点(COMMIT或ROLLBACK),因此,数据库可能处于不正确的状态。数据库的恢复机制要在不影响其他事务运行的情况下,强行撤销该事务中的全部操作,使得该事务就像没发生过一样。
这类恢复操作称为事务撤销(UNDO)。
2.系统故障
系统故障是指造成系统停止运转、系统要重启的故障。例如,硬件错误(CPU故障)、操作系统故障、突然停电等。这样的故障会影响正在运行的所有事务,但不破坏数据库。这时内存中的内容全部丢失,这可能会有两种情况:第一种:一些未完成事务的结果可能已经送入物理数据库中,从而造成数据库可能处于不正确状态;另一种:有些已经提交的事务可能有一部分结果还保留在缓冲区中,尚未写到物理数据库中,这样系统故障会丢失这些事务对数据的修改,也使数据库处于不一致状态。
因此,恢复子系统必须在系统重新启动时撤销所有未完成的事务,并重做所有已提交的事务,以保证将数据库恢复到一致状态。
3.其它故障
介质故障或由计算机病毒引起的故障或破坏,我们归为其它故障。
介质故障指外存故障,如磁盘损坏等。这类故障会对数据库造成破坏,并影响正在操作的数据库的所有事务。这类故障虽然发生的可能性很小,但破坏性很大。
计算机病毒的破坏性很大,而且极易传播,它也可以对数据库造成毁灭性的破坏。