6-2DBMS的故障恢复

来源:互联网 发布:dns污染 知乎 编辑:程序博客网 时间:2024/05/01 04:58

6-2DBMS的故障恢复

数据库故障恢复就是把数据库从错误状态恢复到某一已知的正确状态的功能.

故障的种类

事务内部故障

事务内部故障有预期故障,比如转账时钱不够,但更多是事务故障是非预期的,比如运算溢出,后文中事务故障仅指非预期故障.事务故障意味着事务没有打到预期的终点(COMMIT或者显示的ROLLBACK),因此,数据库可能处于不正确的状态.恢复程序要在不影响其他事务运行的情况下,强行回滚该事务,这类恢复操作称为事务撤销.

系统故障

系统故障是指造成系统停止运转的任何事件,使得系统要重新启动.这类故障影响正在运行的所有事务,但是不破坏数据库.

发生系统故障时,一些尚未完成的事务的结果可能已送入物理数据库,从而造成数据库可能处于不正确的状态.为保证数据一致性,需要清除这些事物对数据库的所有修改.

恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚,强行撤销所有未完成的事务.

发生系统故障时,有些已经完成的事务可能有一部分甚至全部留在缓冲区,尚未写回到磁盘上的物理数据库中,系统故障使得这些事务对数据库的修改部分或全部丢失,这也会使数据库处于一种不一致状态,因此应将这些已经提交的结果重新写入数据库.

恢复子系统必须在系统重新启动后,重做所有已经提交的事务.

介质故障

指外村故障,一般可能性很小,但破坏性最大.

计算机病毒

恢复的实现技术

恢复机制涉及的两个关键问题是:如何建立冗余数据,以及如何利用这些冗余数据实施数据库恢复.

建立冗余的常用技术是:数据转储和登记日志文件.通常一起使用

数据转储

数据转储是数据库恢复中采用的基本技术.所谓转储即数据库管理员定期地将整个数据库复制到磁带,磁盘上,作为后备副本.

重装后备副本只能将数据库恢复到转储时的状态,要恢复到故障发生时的状态,必须重新运行自转储后的所有更新事务.

静态转储

静态转储是系统中无事务运行时进行的转储操作.

动态转储

动态转储是指转储期间允许对数据库进行存取或者修改.即转储和用户事务可以并发执行.但是转储结束后备副本并不能保证数据的有效正确(转储期间有事务修改已经存储的数据),为此必须把转储期间各个事务对数据库的修改活动登记下来,建立日志文件.

日志文件

日志文件的格式和内容

日志文件是用来记录书屋对数据库的更新操作的文件.

日志文件主要有两种格式,一类是以记录为单位的日志文件和以数据块为单位的日志文件.

以记录为单位的日志文件为例:主要包括
1. 事务标识
2. 操作类型
3. 操作对象
4. 数据旧值
5. 数据新值

日志文件的作用

日志文件可以用来进行事务故障恢复和系统故障恢复,并支持后备副本进行介质故障恢复,具体作用是:
1. 事务故障和系统故障恢复必须用日志文件.
2. 在动态转储方式中必须建立日志文件,后背副本和日志文件结合起来才能有效恢复数据库.
3. 在静态转储方式中也可以建立日志文件,当数据库毁坏后可以重新装入后援副本把数据库恢复到转储结束时刻的正确状态,然后利用日志文件把已完成的事务进行重做处理,对故障发生时尚未完成的事务进行撤销处理.

登记日志文件

登记日志文件必须遵从两条原则:
1. 登记的次序严格按照并发事务的执行时间次序.
2. 必须先写日志文件,后写数据库.

恢复策略

事务故障恢复

事务故障是指事务在运行至正常终点前被终止,这是恢复子系统应利用日志文件撤销此事务对数据库的修改.

事务的故障恢复由系统自动完成,对用户是透明的.

系统恢复的步骤
1. 反向扫描日志文件,查找该事务的更新操作.
2. 对事务的更新此操作执行你操作.
3. 继续反向扫描日志文件,查找该事务的其他更新操作,并作同样处理.
4. 循环..

系统故障恢复

系统故障造成数据库不一致的原因有两个:
1. 未完成事务对数据库的更新可能已经写入数据库.
2. 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库.

恢复步骤:
1. 正向扫描日志文件,找出在故障发生前已经提交的事务,这些事务既有begin,又有commit,将其事务标记记入重做队列(redo-list),同时找出故障发生时尚未完成的事务,这些事务只有begin,将其事务标识记入撤销队列(undo-list).
2. 对撤销队列中的各个事务进行撤销(undo)处理.
3. 对重做队列中的各个事务进行重做处理i.

介质故障

介质故障恢复方法是重装数据库,然后重做已经完成的事务.
1. 冲入最新后备副本.
2. 装入相应日志文件.

具有检查点的故障恢复技术

检查点故障恢复技术的优势

利用日志技术进行数据库恢复时,恢复子系统必须搜索日志,确定哪些事务需要重做,哪些事务需要撤销.一般来说,需要检查所有日志记录.这样做有俩个个问题:
1. 搜索整个日志需要消耗大量的时间
2. 很多需要重做的事务实际上已经将他们的更新操作写入到了数据库中,然而恢复子系统又从新做了这些操作,浪费时间.

检查点故障恢复技术的实现

在日志文件冲新加一类记录–检查点记录
增减一个文件,并让恢复子系统在登入日志文件期间动态的维护日志.

检查点记录的内容包括:
1. 建立检查点时刻所有正在执行的事务清单.
2. 这些事务最近一个日志记录的地址.

动态维护日志的方法时是,周期性的执行建立检查点,保存数据库状态的操作,具体如下:
1. 将当前日志缓冲区中所有日志记录写入磁盘的日志文件上.
2. 在日志文件中写入一个检查点记录.
3. 将当前数据缓冲区的所有数据.
4. 把检查点记录在日志文件中的地址写入一个重新开始文件.

当事务在检查点之前提交,事务对数据库所做的修改一定都已经写入的数据库,写入时间在这个检查点建立之前或者在这个检查点建立之时,这样进行回复处理时,没有必须要对事务执行重做操作.

进行恢复的步骤

系统使用检查点恢复步骤:
1. 重新开始文件中找到最后一个检查点记录所在的日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录.
2. 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST.在这里建立两个队列:undo-list:需要执行undo操作的事务集合.redo0list需要执行redo操作的事务集合,把active-list暂时放入undo-list,redo队列为空.
3. 从检查点开始正向扫描日志文件,如果有新开始的事务,把事务暂时放入undo-list,如果有提交的事务,把此事务从undo-list队列放入到redo-list队列;直到日志文件结束.
4. 对undo-list中的每个事务执行undo操作,对redo-list中的每个事务执行redo操作.

0 0
原创粉丝点击