undo日志课案.ppt

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