首页 百科知识 数据库的恢复技术

数据库的恢复技术

时间:2022-10-24 百科知识 版权反馈
【摘要】:以COMMIT结束的事务表示事务成功结束(提交),此时告诉系统,数据库要进入一个新的正确状态,此事务对数据库的所有更新都已经交付实施。恢复子系统必须在系统重新启动上述所有事务,把数据库恢复到正常状态。计算机病毒已成为计算机系统的主要威胁,自然也是数据库系统的主要威胁,因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。因此恢复操作就是要撤销故障发生时未完成的事务,重做已完成的事务。

7.5.2 数据库的恢复技术

尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏,保证并发事务的正确执行,但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的,这些故障轻则造成运行事务非正常中断,影响数据库中数据的正确性,重则破坏数据库,使数据库中全部或部分数据丢失,因此数据库管理系统(恢复子系统)必须具有把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的功能,这就是数据库的恢复。

1.事务(Transaction)的概念

它是数据库环境下的逻辑工作单位,也是数据库的一个联机工作单位,它由一系列操作组成。这些操作要么全部都做,要么一个都不做。它们组成了一个完整的整体,一个不可分割的工作单位。它类似于操作系统中的一个进程,在应用程序中它往往以BEGINTRANSACTION语句开头,而以COMMIT语句或者ROLLBACK语句结束。

img101

以COMMIT结束的事务表示事务成功结束(提交),此时告诉系统,数据库要进入一个新的正确状态,此事务对数据库的所有更新都已经交付实施。

以ROLLBACK结束的事务表示事务不成功结束,此时告诉系统已经发生错误,数据库可能处于不正确的状态,此事务对数据库的更新必须撤销,且应当将数据库恢复到此事务的初始状态。

对于数据库而言,一个程序的执行可以通过若干个事务的执行序列来完成。但应当注意的是事务不能嵌套,可以恢复的操作必须在一个事务的界限内才能执行,即事务必须保持其完整性。

2.事务的性质

研究表明一个事务要保持其完整性必须具有以下4个基本性质:

(1)原子性(Atomicity)

所谓原子性是指一个事务中所有对数据库的操作是一个不可分割的操作序列。事务要么完整地被全部执行,要么什么也不做。

原子性的保证是由DBMS完成的,即由DBMS的事务管理子系统保证实现这种功能。

(2)一致性(Consistency)

所谓数据库的一致性实际上是指数据库中的数据与客观世界的一致性,即正确反映客观世界的数量关系。当一个事务不能完整执行时,就必然破坏数据库中的数据与客观世界之间的一致性。因此事务的原子性保证了事务的一致性。

一个事务的执行结果要保证数据库的一致性,即数据不会因事务的执行而遭受破坏。这一性质的实现是由编写事务的程序员完成的,也可以由系统测试完整性约束自动完成。

(3)隔离性(Isolation)

所谓隔离性是指当执行并发事务时,系统将能够保证与这些事务单独执行时的结果是一样的,此时称事务达到了隔离性的要求。这也就是指一个事务的执行并不关心其他事务的执行情况,如同在单用户环境下执行一样。

事务的隔离性是由DBMS的并发控制子系统来保证的。

(4)持久性(Durability)

所谓事务的持久性是指事务执行时数据库中的数据发生变化,而此变化只有在系统不发生变化时才能实现。事务的持久性保证了事务成功执行后所有对数据库修改的影响应当长期存在不能丢失。一般可通过下述两点保证事务持久性的实现:

●事务的更新操作应当在事务完成之前写入磁盘;

●事务的更新与写入磁盘这两个操作应当保存足够的信息,足以使数据库在发生故障后重新启动时重构更新操作。而DBMS的事务管理子系统和恢复管理子系统的密切配合保证了事务持久性的实现。

一个事务一旦完成全部操作后,其对数据库的所有更新应当永久地反映在数据库中,即使以后系统发生故障,也应当保留这个事务的执行痕迹。

事务的持久性是由DBMS的恢复子系统实现的。

上述4个性质统称为事务的ACID性质。

3.数据库故障的种类

数据库运行时可能发生各种故障,故障发生时可能造成数据损坏,而DBMS恢复管理子系统可采取一系列措施,努力保证事务的原子性与持久性,确保数据不被损坏。

数据库中可能造成数据损坏的故障有以下几种:

(1)事务故障

事务故障又可以区分为以下两种:非预期的事务故障与可以预期的事务故障,即应用程序可以发现的事务故障。对于后一种可以让事务回退(Rollback),以撤销错误的事务故障,恢复数据库到正确的状态。

(2)系统故障(软故障,Soft Crash)

由于软、硬件平台出现问题可能引起内存中数据的丢失,但尚未造成磁盘上的数据破坏,这种情况称为故障终止假设(Fail-stop Assumption)。此时运行的事务全部非正常终止,从而造成数据库系统处于非正常状态。恢复子系统必须在系统重新启动上述所有事务,把数据库恢复到正常状态。

(3)介质故障(硬故障,Hard Crash)

通常为磁盘故障,这种故障一般会造成磁盘上数据的破坏,恢复的方法只能是使用备份。

DBMS应当能够将数据库从被破坏、不正确的状态恢复到时间上最近一个正确状态。

(4)计算机病毒

计算机病毒是具有破坏性、可以自我复制的计算机程序。计算机病毒已成为计算机系统的主要威胁,自然也是数据库系统的主要威胁,因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。

总结各类故障,对数据库的影响有两种可能性。一是数据库本身被破坏,二是数据库没有破坏,但数据可能不正确,这是因为事务的运行被非正常终止造成的。

4.数据库恢复的策略

恢复的基本原理十分简单,可以用一个词来概括就是冗余。这就是说,数据库中任何一部分被破坏的或不正确的数据可以根据存储在系统别处的冗余数据来重建。尽管恢复的基本原理很简单但实现技术的细节却相当复杂。

数据库系统的恢复策略根据故障的不同分为:事务故障的恢复、系统故障的恢复和介质故障的恢复。

(1)事务故障的恢复

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

●反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新操作;

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

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

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

(2)系统故障的恢复

系统故障造成数据库不一致状态的原因有两个,一是未完成事务对数据库的更新可能已写入数据库,二是已提交事务对数据库的更新可能还留在缓冲区未来得及写入数据库。因此恢复操作就是要撤销故障发生时未完成的事务,重做已完成的事务。

系统故障的恢复是由系统在重新启动时自动完成的,不需要用户干预。系统的恢复步骤是:

●正向扫描日志文件(即从头扫描日志文件),找出在故障发生前已经提交的事务(这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录),将其事务标识记入重做(REDO)队列,同时找出故障发生时尚未完成的事务(这些事务只有BEGINTRANSACTION记录,无相应的COMMIT记录),将其事务标识记入撤销队列;

●撤销队列中的各个事务进行撤销(UNDO)处理。进行UNDO处理的方法是,反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作,即将日志记录中“更新前的值”写入数据库;

●重做队列中的各个事务,进行重做(REDO)处理。进行REDO处理的方法是:正向扫描日志文件,对每个REDO事务重新执行日志文件登记的操作,即将日志记录中“更新后的值”写入数据库。

(3)介质故障的恢复

发生介质故障后,磁盘上的物理数据和日志文件被破坏,这是最严重的一种故障,恢复方法是重装数据库,然后重做已完成的事务。具体地说就是:

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

●装入相应的日志文件副本(转储结束时刻的日志文件副本),重做已完成的事务。即首先扫描日志文件,找出故障发生时已提交的事务的标识,将其记入重做队列。然后正向扫描日志文件,对重做队列中的所有事务进行重做处理,即将日志记录中“更新后的值”写入数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态了。

介质故障的恢复需要DBA介入,但DBA只需要重装最近转储的数据库副本和有关的各日志文件副本,然后执行系统提供的恢复命令即可,具体的恢复操作仍由DBMS完成。

5.数据库的恢复技术

数据库恢复机制涉及的两个关键问题是:

第一,如何建立冗余数据;

第二,如何利用这些冗余数据实施数据库恢复。

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

(1)数据转储

所谓转储即DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程,这些备用的数据文本称为后备副本或后援副本。

当数据库遭到破坏后可以将后备副本重新装入,但重装后备副本只能将数据库恢复到转储时的状态,要想恢复到故障发生时的状态,必须重新运行自转储以后的所有更新事务。转储是十分耗费时间和资源的,不能频繁进行。DBA应该根据数据库使用情况确定一个适当的转储周期。

转储分为静态转储和动态转储。

①静态转储

静态转储是在系统中无运行事务时进行的转储操作,即转储操作开始的时刻,数据库处于一致性状态,转储期间不允许(或不存在)对数据库进行任何存取、修改活动。显然,静态转储得到的一定是一个数据一致性的副本。静态转储简单,但转储必须等待正在运行的用户事务结束才能进行,同样,新的事务必须等待转储结束才能执行。显然,这会降低数据库的可用性

②动态转储

动态转储是指转储期间允许对数据库进行存取或修改,即转储和用户事务可以并发执行。动态转储可克服静态转储的缺点,它不用等待正在运行的用户事务结束,也不会影响新事务的运行。但是,转储结束时后援副本上的数据并不能保证正确有效。例如,在转储期间的某个时刻Tc,系统把数据A=100转储到磁带上,而在下一时刻Td,某一事务已将A改为200,可是转储结束后,后备副本上的A已是过时的数据了。为此,必须把转储期间各事务对数据库的修改活动登记下来,建立日志文件(Logfile),这样,后援副本加上日志文件就能把数据库恢复到某一时刻的正确状态。

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

数据转储有两种方式,又分别可以在两种状态下进行,因此数据转储方法可以分为4类:动态海量转储、动态增量转储、静态海量转储和静态增量转储。

(2)登记日志

日志文件是用来记录事务对数据库的更新操作的文件,不同数据库系统采用的日志文件格式并不完全一样。概括起来日志文件主要有两种格式:以记录为单位的日志文件和以数据块为单位的日志文件。

对于以记录为单位的日志文件,日志文件中需要登记的内容包括:

●各个事务的开始(BEGIN TRANSACTION)标记;

●各个事务的结束(COMMIT或ROLL BACK)标记;

●各个事务的所有更新操作。

这里每个事务开始的标记、结束标记和每个更新操作均作为日志文件中的一个日志记录(Log Record)。每个日志记录的内容主要包括:

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

●操作的类型(插入、删除或修改);

●操作对象(记录内部标识);

●更新前数据的旧值(对插入操作而言,此项为空值);

●更新后数据的新值(对删除操作而言,此项为空值)。

日志文件在数据库恢复中起着非常重要的作用,可以用来记录事务故障恢复和系统故障恢复,并协助后备副本进行介质故障恢复。具体地讲:事务故障恢复和系统故障必须用日志文件;在动态转储方式中必须建立日志文件;后援副本和日志文件综合起来才能有效地恢复数据库;在静态转储方式中,也可以建立日志文件;当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态,然后利用日志文件,把已完成的事务进行重做处理,对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态。

为保证数据库是可恢复的,登记日志文件时必须遵循两条原则:

●严格按并发事务执行的时间次序;

●必须先写日志文件,后写数据库。

把对数据的修改写到数据库中和把写表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障,即这两个写操作只完成了一个。如果先写了数据库修改,而在运行记录中没有登记下这个修改,则以后就无法恢复这个修改了。如果先写日志,但没有修改数据库,按日志文件恢复时只不过是多执行一次不必要的UNDO操作,并不会影响数据库的正确性。所以为了安全,一定要先写日志文件,即首先把日志记录写到日志文件中,然后写数据库的修改,这就是“先写日志文件”的原则。

6.数据库的镜像

我们已经看到,介质故障是对系统影响最为严重的一种故障。系统出现介质故障后,用户的应用全部中断,恢复起来也比较费时。而且DBA必须周期性地转储数据库,这也加重了DBA的负担。如果不及时而正确地转储数据库,一旦发生介质故障,会造成较大的损失。

随着磁盘容量越来越大,价格越来越便宜,为避免磁盘介质出现故障影响数据库的可用性,许多数据库管理系统提供了数据库镜像(Mirror)功能用于数据库恢复。即根据DBA的要求,自动把整个数据库或其中的关键数据复制到另一个磁盘上。每当主数据库更新时,DBMS自动把更新后的数据复制过去,即DBMS自动保证镜像数据与主数据的一致性。这样,一旦出现介质故障,可由镜像磁盘继续提供使用,同时DBMS自动利用镜像磁盘数据进行数据库的恢复,不需要关闭系统和重装数据库副本。在没有出现故障时,数据库镜像还可以用于并发操作,即当一个用户对数据加排他锁修改数据时,其他用户可以读镜像数据库上的数据,而不必等待该用户释放锁。

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

保证数据一致性是对数据库的最基本的要求。事务是数据库的逻辑工作单位,只要DBMS能够保证系统中一切事务的原子性、一致性、隔离性和持续性,也就保证了数据库处于一致状态。为了保证事务的原子性、一致性与持续性,DBMS必须对事务故障、系统故障和介质故障进行恢复。数据库转储和登记日志文件是恢复中最经常使用的技术。恢复的基本原理就是利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库。综上所述数据库的恢复大致有如下办法。

①周期性地(如3天一次)对整个数据库进行转储,把它复制到备份介质中(如磁带),作为后备副本,以备恢复之用。转储通常又可分为静态转储和动态转储。静态转储是指转储期间不允许对数据库进行任何存取、修改活动。而动态转储是指在存储期间允许对数据库进行存取或修改。

②对数据库的每次修改,都记下修改前后的值,写入“运行日志”数集中。它与后备副本结合,可有效地恢复数据。

日志文件是用来记录对数据库每一次更新活动的文件。在动态转储方式中必须建立日志文件,后备副本和日志文件综合起来才能有效地恢复数据库。在静态转储方式中,也可以建立日志文件。当数据毁坏后可重新装入后备副本把数据恢复到转储结束时刻的正确状态。然后利用日志文件,把已完成的事务进行重新处理,对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序,就可把数据恢复到故障前某一时刻的正确状态。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈