觉得这种基础的东西，有必要记录下来进行学习。
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)技术
让恢复子系统在登陆日志文件 期间动态的维护日志。
检查点记录包括：
- 建立检查点 时刻所有正在执行的事务清单
- 这些事务最近 一个日志记录地址
重新开始文件用来记录检查点 记录再日志文件中的位置
动态维护日志文件的方法是，周期性的执行建立检查点，保存数据库状态的操作。
将当前日志缓冲器的所有日志记录写入磁盘的日志文件上。
在日志文件中写入一个检查点记录
将当前缓冲区的数据写入磁盘的数据库中
吧检查点再日志文件中的地址写入一个重新开始文件
使用检查点方法可以改善恢复效率
在回复的时候，将根据事务与检查点的管理采取不同的回复策略
数据库镜像#
实际应用中一般只对关键数据和日志文件进行镜像，而不是整个数据库文件。
