1-事务
1-1定义
一个数据库操作序列
一个不可分割的工作单位
恢复和并发控制的基本单位
一个不可分割的工作单位
恢复和并发控制的基本单位
1-2事务的ACID特性:
原子性(Atomicity)一致性(Consistency)
隔离性(Isolation)
持续性(Durability )
2-故障
2-1 故障的种类
(1) 事务内部的故障:事务故障的恢复:撤消事务(UNDO)
(2) 系统故障:是指造成系统停止运转的任何事件,使得系统要重新启动。
- 整个系统的正常运行突然被破坏
- 所有正在运行的事务都非正常终止
- 不破坏数据库
- 内存中数据库缓冲区的信息全部丢失
发生系统故障时,事务未提交:
恢复策略:强行撤消(UNDO)所有未完成事务
发生系统故障时,事务已提交,但缓冲区中的信息尚未完全写回到磁盘上。
恢复策略:重做(REDO)所有已提交的事务
恢复策略:强行撤消(UNDO)所有未完成事务
发生系统故障时,事务已提交,但缓冲区中的信息尚未完全写回到磁盘上。
恢复策略:重做(REDO)所有已提交的事务
(3)介质故障
(4)计算机病毒
3-数据恢复技术
3-1 数据转储
转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程,备用的数据称为后备副本或后援副本
如何使用:
数据库遭到破坏后可以将后备副本重新装入
重装后备副本只能将数据库恢复到转储时的状态
如何使用:
数据库遭到破坏后可以将后备副本重新装入
重装后备副本只能将数据库恢复到转储时的状态
3-2 登记日志文件
(1)日志文件的格式:
以记录为单位的日志文件
以数据块为单位的日志文件
以记录为单位的日志文件
以数据块为单位的日志文件
(2)以记录为单位的日志文件内容
各个事务的开始标记(BEGIN TRANSACTION)
各个事务的结束标记(COMMIT或ROLLBACK)
各个事务的所有更新操作
各个事务的开始标记(BEGIN TRANSACTION)
各个事务的结束标记(COMMIT或ROLLBACK)
各个事务的所有更新操作
(3)基本原则
登记的次序严格按并行事务执行的时间次序
必须先写日志文件,后写数据库
登记的次序严格按并行事务执行的时间次序
必须先写日志文件,后写数据库
- 如果先写了数据库修改,而在日志文件中没有登记下这个修改,则以后就无法恢复这个修改了
- 如果先写日志,但没有修改数据库,按日志文件恢复时只不过是多执行一次不必要的UNDO操作,并不会影响数据库的正确性
(4)日志文件的作用
进行事务故障恢复
进行系统故障恢复
协助后备副本进行介质故障恢复
进行系统故障恢复
协助后备副本进行介质故障恢复
4-数据库恢复策略
4-1 事务故障的恢复
事务故障:事务在运行至正常终止点前被终止
恢复方法:由恢复子系统应利用日志文件撤消(UNDO)此事务已对数据库进行的修改
恢复注意:事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预
恢复方法:由恢复子系统应利用日志文件撤消(UNDO)此事务已对数据库进行的修改
恢复注意:事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预
恢复步骤:
- 反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新操作。
- 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值” 写入数据库。
- 插入操作, “更新前的值”为空,则相当于做删除操作
- 删除操作,“更新后的值”为空,则相当于做插入操作
- 若是修改操作,则相当于用修改前值代替修改后值
- 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
- 如此处理下去,直至读到此事务的开始标记,事务故障恢复就完成了。
4-2 系统故障的恢复
(1)系统故障造成数据库不一致状态的原因:
未完成事务对数据库的更新已写入数据库
已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
(2)恢复方法:
1. Undo 故障发生时未完成的事务
2. Redo 已完成的事务
(3)恢复注意:系统故障的恢复由系统在重新启动时自动完成,不需要用户干预
未完成事务对数据库的更新已写入数据库
已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
(2)恢复方法:
1. Undo 故障发生时未完成的事务
2. Redo 已完成的事务
(3)恢复注意:系统故障的恢复由系统在重新启动时自动完成,不需要用户干预
(4)恢复步骤:
- 正向扫描日志文件(即从头扫描日志文件)
- 创建重做(REDO) 队列: 在故障发生前已经提交的事务:这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录
- 创建撤销 (Undo)队列:故障发生时尚未完成的事务:这些事务只有BEGIN TRANSACTION记录,无相应的COMMIT记录
- 对撤销(Undo)队列事务进行撤销(UNDO)处理
- 反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作
- 即将日志记录中“更新前的值”写入数据库
- 对重做(Redo)队列事务进行重做(REDO)处理
- 正向扫描日志文件,对每个REDO事务重新执行登记的操作
- 即将日志记录中“更新后的值”写入数据
4-3 介质故障的恢复
- 重装数据库
- 重做已完成的事务
4-4 具有检查点的恢复策略
(1)解决了两个问题:
- 搜索整个日志将耗费大量的时间
- REDO处理:重新执行,浪费了大量时间
(2)使用检查点方法可以改善恢复效率
- 当事务T在一个检查点之前提交:T对数据库所做的修改已写入数据库
- 写入时间是在这个检查点建立之前或在这个检查点建立之时
- 在进行恢复处理时,没有必要对事务T执行REDO操作
(3)示例
- T1:在检查点之前提交
- T2:在检查点之前开始执行,在检查点之后故障点之前提交
- T3:在检查点之前开始执行,在故障点时还未完成
- T4:在检查点之后开始执行,在故障点之前提交
- T5:在检查点之后开始执行,在故障点时还未完成
- T3和T5在故障发生时还未完成,所以予以撤销
- T2和T4在检查点之后才提交,它们对数据库所做的修改在故障发生时可能还在缓冲区中,尚未写入数据库,所以要REDO
- T1在检查点之前已提交,所以不必执行REDO操作
(5)并发
- 丢失修改:两个同时修改,一个覆盖另一个
- 不可重复读:一个读取了。另一更新它,导致第一个事务不能再现
- °脏数据:数据不一致,一个改了又撤销,另一个读的和数据库不一样
(6)封锁
1、活锁的避免:先来先服务,解决一个一直在等待的问题
2、死锁的预防:
- 一次封锁法:降低并发性
- 顺序封锁法:维护顺序成本太大
3、死锁的诊断与接触
- 超时法
- 等待图法:不要出现环
(7)可串行化调度
如果一个并发调度的结果与一个串行调度等价,则称此调度是是可串行化调度。
(8)两段锁协议
- 1. 在对任何数据进行读、写操作之前,事务首先要获得对该数据的封锁
- 2. 在释放一个封锁之后,事务不能再获得任何其他封锁。