首页 百科知识 利用事务日志恢复数据库的原理

利用事务日志恢复数据库的原理

时间:2022-10-21 百科知识 版权反馈
【摘要】:以下介绍三种类别的故障及其恢复方法。发生事务故障时,夭折的事务可能已经对数据库进行了修改。即将日志记录中“更新前的值”写入数据库。发生介质故障后,存储在磁盘上的数据被破坏,这时需要装入数据库发生介质故障前某个时刻的数据副本,并重做自此时开始的所有成功事务,将这些事务已提交的结果重新记入数据库。

7.2.1 数据库的恢复

事务是数据库的基本工作单位,由有限的数据操作序列组成,这些操作要么全做,要么全不做,是一个不可分割的工作单位。如果数据库中只包含成功事务提交的结果,就说明此数据处于一致性状态;如果数据库系统运行中发生故障,有些事物尚未完成就被迫中断,这些未完成事物对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于不正确的状态,就需要DBMS的恢复系统,根据故障类型采取相应的措施,将数据库恢复到某种一致状态。以下介绍三种类别的故障及其恢复方法。

1)事务故障及其恢复

事务故障是指事务在运行过程中由于某种原因使事务未运行至正常就出现错误。发生事务故障时,夭折的事务可能已经对数据库进行了修改。恢复程序要在不影响其他事务运行的情况下,强行回滚该事务。具体的做法如下:

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

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

(3)继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。(4)如此处理下去,直至读到此事务的开始标记,事务故障恢复就完成了。2)系统故障及其恢复

系统故障是指系统在运行过程中,由于某种原因,致使所有正在运行的事务以非正常的方式终止。这时内存中数据缓冲区的信息全部丢失,但存储在外部存储设备上的数据未受影响。系统故障的恢复的做法如下:

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

(2)对撤销队列中的各个事务进行撤销(UNDO)处理。

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

(3)对重做队列中的各个事务进行重做(REDO)处理。

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

3)介质故障及其恢复

介质故障是指系统在运行过程中,由于某种硬件故障,如磁盘损坏,磁头碰撞,或操作系统的某种潜在错误,瞬时强磁场干扰等,使存储在外存中的数据部分丢失或全部丢失的情况。发生介质故障后,存储在磁盘上的数据被破坏,这时需要装入数据库发生介质故障前某个时刻的数据副本,并重做自此时开始的所有成功事务,将这些事务已提交的结果重新记入数据库。具体做法如下:

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

(2)装入有关的日志文件副本,重做已完成的事务,即:

首先扫描日志文件,找出故障发生时已提交的事务的标识,将其记入重做队列。然后正向扫描日志文件,对重做队列中的所有事务进行重做处理,即将日志记录中“更新后的值”写入数据库。

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

我要反馈