undo日志分析

缺点：进行 检查点时必 须关闭系统
5、重新开始接收事务
2.3 检查点——非静止检查点
非静止检查点优势：在系统进行检查点时允许新事务进入
写入日志记录<START CKPT(T1….k)>并刷新日志，其中T是所有活 跃事务的名字或标识符
非静 止检 查点 步骤
等待T1,…,k中的所有事务提交或中止，但允许其他事务开始
2 undo日志
• 日志是日志记录构成的文件，每个日志记录记载有关某个 事务已做的事的某些情况 • 事务终止不提交原因：
事务自身的代码中有某些错误情况。 也可能由于一个或多个原因需要中止事务。比如事务可能陷入死锁中，此时 该事物和其它事务各自占有其他事务等待的某个资源。
• 日志记录的形式
1 <START T>：事务开始 2 <COMMIT T>：事务已完成且对数据元素不会有修改 3 <ABORT T>：事务T不能成功完成
日志规 则重要 性举例
续2.2 日志恢复
按照日志恢复的顺序 原因：日志中可能有多个未提交的事务，并且可能有多个未提交的事务修改了X， 所以在日志在恢复值得顺序上必须是有计划的。 规则：恢复管理器从尾部开始扫描日志，过程中记住所有的<COMMIT T> 或<ABROT T>记录事务T。
向后扫 描，遇 到 <T,X,v>
数据库系统实现 ——undo日志
姓名：周兵 学号：1511414012
主要内容
• 1. 背景介绍
1.1 故障模式 1.2 事务
• 2.undo日志
2.1 日志规则 2.2 日志恢复 2.3 检查点
1. 背景介绍
• 控制数据访问两大问题： 1.1 当系统故障发生时数据必须收到保护，保护数据完整性 2.1 数据不能仅仅因为几个本身无措的查询或数据库更新同 时进行就受到破坏。 • 日志支持数据库的可恢复性 • 恢复是故障发生后使用日志重建对数据库所做更新的过程
1.2 事务
• 查询和修改数据库的进程称为事务 • 事务是数据库操作执行的单位
• 事务的四大特性：
A:原子性(Atomicity) 事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做 B:一致性(Consistency) 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与 原子性是密切相关的。 C:隔离性(Isolation) 一个事务的执行不能被其他事务干扰。 D:持续性/永久性(Durability) 一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。要么全不做。
当T1，…,k都已完成时，写入日志记录<END CKPT>并刷新日志
实例1——原语步骤序列
事务T可表述为下面6个相关步骤的序列
则原语操作步骤为：
实例2——undo日志的建立
事务T可表述为下面6个相关步骤的序列
则undo日志的建立如下：
实例3——undo日志的恢复
根据规则U1，使用相应 的日志记录撤销更改
1.1 故障模式
• 1、错误数据输入 例如：电话号码的错误位和少输入一位。 解决方法：可以通过编写约束和触发器来找出被认为是错 误的数据。 • 2、介质故障 例如：磁盘故障 解决方法：可以通过与磁盘扇区相关联的奇偶校验检测到 • 3、灾难性故障 介质完全损坏，可以通过备份或者拷贝方法解决 • 4、系统故障 导致事务状态丢失的问题，比如掉电、软件错误。
事务未完成，撤销更改 事务未完成，撤销更改 可能到达磁盘，也可能未到 达，看是否包含COMMIT 不撤销T的结果
实例4——静止检查点
若日志的一种情况如下： 开 始
后 续
扫描规则 当我们看到<CKPT>记录时，则已经看到了所有未完成 的事务。由于只有在检查点结束后事务才能开始，因此 必然已经看到了关于未完成事务的所有日志记录。所以 没有碧瑶扫描<CKPT>以前的部分，并且事实上将改点 以前的日志删除或覆盖是安全的
续1.2 事务
• 原语操作： 1、INPUT(X):将包含数据库元素X的磁盘块拷贝到主存缓 冲区 2、READ(X,t):将数据库元素X拷贝到事务的局部变量t。 即若X不在主存缓冲区中，此原语可将值赋给局部变量t 3、WRITE(X,t):将局部变量t拷贝到主存缓冲区中的数据元 素X 4、OUTPUT(X):将包含X的缓冲区中的块拷贝回磁盘
若扫描到 COMMIT 记录，则 什么也不 错，无需 撤销
若无COMMIT，则T是未 完成事务或一个中止事务。 必须将数据库中X的值改 为v，以防万一恰好在系 统崩溃前X已经被修改了
2.3 检查点——静止检查点
恢复需要检查整个日志 需要 检查 点原 因 采用undo类型的日志，一旦事务的COMMIT日志记录被写到磁盘上，该事务 的日志记录在恢复时就不在需要。但有时却不能删除它。原因在于许多事务 同时执行，可能会丢失某个活跃事务T的日志记录，从而不能在需要进行恢复 时用来撤销T。 1、停止接收新的事务 检查点 可以解 决的问 题 2、等到所有当前活跃的事务提交或中止并且在日志中写入 了COMMMIT或ABORT记录 3、将日志刷新到磁盘 4、写入日志记录<CKPT>，并再次刷新日志
指明所改变 数据库元素 的日志记录
改变的数据 库元素自身
COMMIT日 志记录
2.2 日志恢复
恢复原因：如果故障发生了，可能给定事务的某些数据库更新已经写入到 磁盘上，而同一事务的另一些更新尚未到达磁盘。如此破坏了数据库的原 子特性，数据库一致性也得不到保证。 恢复管理器：使用日志来将数据库恢复到某个一致的状态
日志恢复主要利用日志Biblioteka Baidu两个重要规则
如果有日志记录<COMMIT T>，根据undo规则U2，事务T所做 的全部改变在此之前已写到磁盘上。因此当系统故障发生时， T自身不可能使数据库保持不一致的状态 如果在日志上发现<START T>记录，但未发现<COMMIT T> 记录，规则U1保证如果T在崩溃前改变了磁盘上的X，那么日 志中就会有<T,X,v>记录，并且该记录在崩溃发生前已被拷贝 到磁盘。
续2 undo日志
2.1 日志规则
U1：如果事务T改变了数据库元 素X，那么形如<T,X,v>的日志 记录必须在X的新值写到磁盘之 前写到磁盘中 两个重要 规则 U2：如果事务提交，则其 COMMIT日志记录必须在事务 改变所有的数据库元素先写到磁 盘之后写到磁盘中
续2.1 日志规则
规则U1和U2与一个事物相关内容写入到磁盘的 顺序