觉得这种基础的东西,有必要记录下来进行学习。
1 事务
一般是 begin transaction commit rollback 三个步骤
2 acid 特性
原子性(Atomicity) , 一致性(Consistency) , 隔离性 (Isolation) , 持续性 (Durability)

A 要么都做 要么都不做

C 事务的执行结果是 使得数据库 从一个一致性状态 到另外一个一致性 状态

I 一个事务的执行 不能被其他事务 干扰 吗即一个事务的内部操作及其使用对其他 并发事务是隔离的

D 也称为永久性(Permanence) 一个事务一旦提交,它对数据库的改变就是永久性的 ,接下来的其他操作或者故障 不应该对它有影响

事务ACID 特性被破坏的可能因素有

  • 多个事务并行运行时,不同事务的交叉操作

  • 事务在运行的时候强制停止

故障的种类

事务故障(运算溢出 死锁 违反完整性约束)
事务内部的故障通常是非预期的 , 不能由应用程序处理的,即没有到达预计的终点 (commit 或者是 rollback) , 针对这种情况的回复操作称为 事务撤销 (UNDO)

系统故障(CPU 错误 硬件错误 系统故障 代码错误 断电)
有一些已经提交的事务 还留在缓冲区 没有提交写回物理硬盘 (针对这种情况) ,我们不仅要撤销所有未完成的事务, 还要重做已完成的事务

介质故障(磁盘损坏,强磁场干扰)
上例系统故障称为软故障
介质故障称为硬故障

计算机病毒

数据库恢复的原理十分简单:冗余。

恢复的实现技术##

建立冗余数据的最常用技术是 数据转储 和 登记日志文件

数据转储##

数据转储只能将数据恢复到转储时的状态,要想到故障发生时的状态还要重新运行自转储以后的所有事务。
转储是十分耗时的,根据使用情况,合理设置数据库的转储周期

静态转储是再无事务进行的情况下进行的,转储必须等待用户事务结束才能进行

动态转储
动态转储需要对转储期间的事务的事务登记下来 建立日志文件

backup + logfie 就可以报数据库恢复到某一时刻的正确状态

转储还有海量转储和增量转储的区别

海量转储 从恢复的角度更方便一些, 但是增量转储再数据量较大的时候更加的方便

等级日志文件##

日志文件是记录事务对数据库进行更新操作的文件

日志文件主要由两种格式
以记录为单位的日志文件 和 以数据块为单位的日志文件

日志文件的原则:
登记的次序按照并发事务执行的先后顺序
先写日志文件,后写数据库

恢复策略#

事务故障的恢复##

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

(2) 对事务中的更新事务进行逆操作(如果是插入 那么就删除 修改就依据表中更新前的值进行修改)

(3) 继续反响操偶做

(4) 直到该事务的开始标记处

系统故障的恢复##

造成不一致的原因有两个:

1 未完成的事务对数据库的更新操作 可能已经写入数据库

2 已提交事务对数据库的更新 可能留在 缓冲区没有写入硬盘

步骤

1 正向扫描日志文件,
找到所有已经提交的事务 既包括 begin transaction 和 commit 将这些事务重新加入 redo-list

对所有未完成的事务 只有 transaction 没有commit 的 进行撤销操作

2对 撤销队列中的 进行撤销 undo

3对 重做队列中的 进行重做 redo

介质故障的恢复

(1) 重新装入 数据库副本

(2) 装如对应的日志副本文件 ,重做已经完成的事务

具有检查点的恢复技术#

检查点记录(checkpoint)技术

让恢复子系统在登陆日志文件 期间动态的维护日志。

检查点记录包括:

  • 建立检查点 时刻所有正在执行的事务清单
  • 这些事务最近 一个日志记录地址

重新开始文件用来记录检查点 记录再日志文件中的位置

动态维护日志文件的方法是,周期性的执行建立检查点,保存数据库状态的操作。

将当前日志缓冲器的所有日志记录写入磁盘的日志文件上。

在日志文件中写入一个检查点记录

将当前缓冲区的数据写入磁盘的数据库中

吧检查点再日志文件中的地址写入一个重新开始文件

使用检查点方法可以改善恢复效率

在回复的时候,将根据事务与检查点的管理采取不同的回复策略

数据库镜像#

实际应用中一般只对关键数据和日志文件进行镜像,而不是整个数据库文件。