数据库的恢复技术

更好的阅读体验

存储器结构

分类

1、易失性存储器:内存、高速缓冲存储器
2、非易失性存储器:磁盘、磁带
3、稳定存储器:理想的存储器,其中信息永不丢失

稳定存储器的实现

要实现稳定存储器,就要在多个非易失性存储介质上以独立的故障模式复制所需要的信息,并且以某种受控的方式更新数据,以保证数据传送的过程中发生的故障不会破坏所需信息
采用冗余独立磁盘阵列(RAID)可以保证单个磁盘的故障不会导致数据丢失。

数据访问

数据库通常驻留在磁盘上,并且划分成固定长度的块。块是磁盘传送的基本单位,可能包含多个记录。
缓冲块是暂时驻留在主存中的块,物理块位于磁盘上.
8.png
9.png

基于日志的恢复技术

日志

1、日志是日志记录的序列,记录了数据库中所有的更新活动。登记了每个事务的开始标记、结束标记、和所有更新操作
2、事务结束可能是正常提交(commit)、也可能是异常终止(abort)
3、事务的更新可能是插入、删除、更改
11.png
10.png
登记日志的原则
1、日志记录必须严格按并发事务的时间次序登记
2、必须先记日记后写数据库

redo(Ti):根据日志记录,登记日志的次序,将事务Ti每次更新的数据对象的新值用write操作重新写到数据库中。redo执行多次等价于执行一次
undo(Ti):根据日志,按照登记日志的相反次序,将事务Ti每次更新的数据对象的旧值用write操作写回数据库。

延迟更新

将对事务的更新推迟到事务提交之后遵循以下原则
(1)、每个事务在到达提交点之前不能更新数据库
(2)、在一个事务的所有更新操作的日志记录写入稳定存储器之前,该事务不能达到提交点

延迟更新技术只需要在日志中记录被更新数据对象的新值

事务故障的处理:12.png

系统故障的处理

13.png
14.png
对于(a)时刻:这时没有commit所有事务都未提交所以不用管
对于(b)时刻:T0commit所以对T0事务执行redo
c:T0、T1均commit执行redo

即时更新

允许事务在活跃状态时就将更新输出到数据库上。处于活动状态的事务直接在数据库上实施的更新称为非提交更新。遵循以下原则
(1)、在<Ti, Xj, V1, V2>安全地输出到稳定性存储器之前,事务Ti不能更新
(2)、在所有<Ti, Xj, V1, V2>类型的日志记录安全地输出到稳定存储器之前,不孕寻事务提交
15.png

事务故障处理

16.png

系统故障的处理

17.png
18.png

延迟更新和即时更新对数据库的恢复的不同之处就是因为更新数据库的时间不同导致,延迟更新是用已经commit的去恢复,没有commit的我们本身没有对数据库操作也就不用恢复,而即时更新是我们在commit之前只要日志记录成功我们就可以更新数据库,一旦出现故障,那些没有commit的我们用记录中的旧值去更新,commit的用新值去更新。

基于检查点的恢复技术

对于系统故障恢复时,必须搜索日志,确定哪些事务是需要redo的,哪些事务是需要undo的,这个过程需要搜索整个日志,这里就会有两个问题
1、日志一般来说很大,搜索起来很耗时
2、有些事务已经写入数据库,再次执行redo虽然不会错,但是会耗时
检查点技术的使用就很好的解决了这两个问题
通过定期建立检查点来解决
21.png
基于即时更新的检查点恢复过程
22.png
23.png
19.png
20.png

介质故障恢复技术

虽然介质故障不常见但危害巨大
首先说一下转储的概念
转储是指将整个或部分数据库复制到磁带或另一个磁盘上,产生数据库后备副本的过程。根据转储时是否允许事务运行可以分为静态转储和动态转储
静态转储
24.png
动态转储
25.png
海量转储和增量转储
26.png
27.png

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值