数据库复习7——恢复

页面导航:首页 > 数据库 > DB2 > 数据库复习7——恢复

数据库复习7——恢复

来源: 作者: 时间:2016-01-23 11:15 【

数据库复习CH14 恢复13 1 恢复的概念数据库系统中恢复是指让数据库从发生某些失败后的不一致的状态恢复到正常的一致状态的行为,恢复的基础是冗余(物理上冗余,非逻辑上)这些失

数据库复习


CH14 恢复

13.1 恢复的概念

数据库中恢复是指让数据库从发生某些“失败”后的不一致的状态恢复到正常的一致状态的行为,恢复的基础是冗余(物理上冗余,非逻辑上)

这些失败包括了:

事务失败:包括逻辑错误(事务不满足某些条件不能执行)和系统错误(DBMS强制终止事务,如事务发生死锁) 系统崩溃:断电、物理硬件损坏、软件系统(如OS)崩溃,本章假设系统崩溃不会改变非易失存储器 磁盘失败:磁盘存储发生错误,本章假设可利用检查和监测磁盘失败

大体上,恢复策略分成两个步骤:

正常事务处理时,记录足够的额外信息以供失败时恢复 失败发生后,讲数据库返回一致性状态的动作

13.2 存储结构和数据访问

本小节假设讨论恢复问题时的存储结构和数据访问模型

按系统奔溃时是否影响数据存储,将存储器分成易失存储器(主存、cache等)和非易失存储器(磁盘磁带、闪存、非易失RAM等),然后我们假设一种理想的稳定存储器(stable storage),发生任何失败时都不会影响存储数据内容

定义物理块为存储在非易失的磁盘上的块,缓冲块是为存储在易失的主存中的块,而私有空间是指为每个事务T分配的独立于其他事务的虚拟存储区域,那么可以命名一下4种操作:

input(A):从磁盘中加载物理块到主存 output(A):把主存中缓冲块写回磁盘 read(X):从主存中将缓冲块读取到私有空间 write(X):把私有空间中的本地副本写回到主存

假设在事务中,DBMS在第一次访问块X时调用一次read操作加载到私有缓冲区,事务执行完毕时write(X)写回主存,而事务中间的操作时都只是修改其本地副本

注意,DBMS没有必要在每次write时调用output,这取决于OS的写回策略

13.3 基于日志的恢复

日志是一组记录在理想的稳定存储器上的数据库存储记录,约定:

事务Ti开始时,日志记录<Ti, start> 事务Ti执行write操作时,日志记录<Ti, X, old_value, new_value> 事务Ti结束时,日志记录<Ti, commit> 任何时候最多只有一个事务活跃

基于日志的恢复有两种策略,推迟数据库修改立即数据库修改

(1)推迟数据库修改

推迟数据库修改模式下,数据库的修改操作仅记录在Log中而不真正的实施write操作,直到partial committed之后才write

定义在失败发生时的redo和undo操作:

redo:按照Log中的<Ti, X, old_value, new_value>再一次写入新值new_value undo:按照Log中的<Ti, X, old_value, new_value>撤销新值写入,即写入old_value

由推迟数据库修改模式的定义知,未记录<Ti, commit>的事务不执行任何恢复操作,已记录<Ti, commit>的事务顺序地执行redo操作(其实这种模式下old_value是没有必要记录的)

(2)立即数据库修改

立即数据库修改模式和推迟数据库修改模式相反,事务未commit之前就允许修改数据库,write-ahead logging rule(WAL规则)规定log记录必须在数据库写入之前完成

立即数据库修改下,未记录<Ti, commit>的事务必须反序地执行undo操作让数据库返回到一致性状态,而已记录<Ti, commit>的事务顺序地执行redo操作

(3)检查点

每次redo和undo时都遍历整个Log并完成所有事务的redo和undo的话,开销十分巨大,并且对于已经commit后output写入磁盘的redo是没有任何意义的,因此在Log引入<checkpoint>语句

DBMS周期性地做检查工作,把所有commit的事务(已write入主存)从主存中写回到磁盘中,并在日志中记录一条<checkpoint>;注意检查时,可能某个事务还未commit

有了检查点的数据库恢复,每次错误时只需恢复最近的事务即可:

反向遍历日志,直到找到第一个<checkpoint> 继续反向遍历,找到最近一个未commit的事务起点<Ti, start> 从该句开始执行响应的redo和undo操作

那么对于下面的时序图,发生失败时有(立即数据库修改模式):

这里写图片描述

T1被忽略 redo T2和T3 undo T4

13.4 影子数据库

除了基于日志的恢复,还另一种恢复策略——影子数据库(Shadow Database),它有以下设定

假设任何时候只有一个事务活跃 db_pointer指针总是指向数据库当前的一致性副本 所有的update都是在数据库的影子拷贝(shadow copy)上完成的,只有当事务partial committed之后才把影子拷贝中的副本写入磁盘中,并且更新db_pointer 事务失败时转向db_pointer指向的一致性的数据库,当前影子数据库被直接删除 假设磁盘不会失败

影子数据库的拷贝策略运用在大型数据库上十分低效

13.5 并发事务的恢复

13.3中介绍的基于Log的恢复是针对单活跃事务而言的,下面进行更多的假设已完成对并发事务的恢复

所有的事务共享一份存储缓冲和一份日志记录 一个缓冲块中可以有多个事务修改后的数据 并发控制严格遵循两阶段锁(下一章详细描述),保证未commit的事务间不可见 并发事务的Log可以交织在一起 检查点发生时,可能有多个事务正处在活跃状态,记录<checkpoint, L>,L是检查点发生时活跃的事务列表 当失败发生时执行一下动作:初始化undo_list和redo_list为空表,倒序找到第一个<checkpoint, L>,对于L中每一个事务的update按Log记录反序加入undo_list、正序加入redo_list 执行undo_list和redo_list中的操作

13.6 缓存管理

(1)Log记录缓存

如果把Log缓存在主存中,那么当缓存已满log force操作时才把Log记录(全部)写入磁盘(这样多条log记录可以一次output,减少I/O开销),此外Log记录缓存还必须遵从以下约定:

log记录必须顺序地output进磁盘 事务Ti只有当<Ti, commit>写入磁盘后才能进入Committed状态 log记录必须比相应修改后的数据先写入磁盘

(2)数据库缓存

数据库缓存和Log记录缓存不一样的是,它是分块划分缓存的,当缓存满时是选择缓存块被新块替换(若修改需要写回磁盘),而不整个缓存写回

13.7 非易失存储器的失败

上述对恢复的讨论仅包含易失存储器的部分,非易失存储器的恢复也利用了相似的分层存储器思想:增加一种dump操作,它下一级是理想的稳定存储器(可以假想为磁带等层次更低的存储介质)

Tags:

文章评论

最 近 更 新
热 点 排 行
Js与CSS工具
代码转换工具

<