第十章 数据库恢复

了解

数据库的一致性状态

  数据库运行中可能产生的故障类型，它们如何影响事务的正常执行，如何破坏数据库数据

  数据转储的概念及分类

  数据库的镜像功能

掌握

事务的基本概念和事务的ACID性质(*)

数据库恢复的实现技术

日志文件的内容及作用

登记日志文件所要遵循的原则

具有检查点的恢复技术

恢复的基本原理

针对不同故障的恢复策略和方法

日志文件的使用

事务？ACID特性？

事务是用户定义的一个数据库操作序列，这些操作要么全做、要么全不做，是一个不可分割的工作单位事务具有4个特性（也称ACID特性）

一句话：要么一口吃完，要么一口都不吃

A（原子性tomicity）

原子性指的是像原子一样不可分割，要么都做，要么不做，没有说做一半或者留一些

C（一致性Consistency）

一致性指的是事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态

I（隔离性 Isolation）

隔离性指的是一个事务的执行不能被其他事务所有干扰。

D（持续性Durability）

持续性指的是一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

为什么事务非正常结束时会影响数据库数据的正确性，举例说明

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

例如某工厂的库存管理系统中，要把数量为Q的某种零件从仓库1移到仓库2存放。则可以定义一个事务T，T包括两个操作；Q1=Q1-Q，Q2=Q2+Q。如果T非正常终止时只做了第一个操作，则数据库就处于不一致性状态，库存量无缘无故少了Q。

登记日志文件时为什么必须先写日志文件，后写数据库？

把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。

如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。

如果先写日志，但没有修改数据库，在恢复时只不过是多执行一次UNDO操作，并不会影响数据库的正确性

所以一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。

例如案例分析

解析：

当需要用日志记录恢复时，只要牢记还是从序号1开始往下执行：

REDO队列处理：如果已经提交的了就要 重做

UNDO队列处理：已经回滚了/未回滚 都要重新回滚

如果没有开始的事务 就不需要操作

例如第一题：因为系统故障发生在序号14后，由图可知T1在序号6时提交了，T3在序号13提交了，所以T1和T3都需要重做。

而T2，T4都未在序号14内有提交过，只是T2回滚了而已，那么就是第二种情况，回滚就行了

其他的类似推理。结合故障发生在序号几之后就行了，故障发生后面的序号都无效，因为没有执行到那步就已经故障了

事务故障的恢复步骤

反向扫描文件日志，查找该事务的更新操作。

对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。直至读到此事务的开始标记，该事务故障的恢复就完成了。

系统故障的恢复步骤

正向扫描日志文件，找出在故障发生前已经提交的事务队列（REDO队列）和未完成的事务队列（UNDO队列）。

对未完成的事务队列中的各个事务进行UNDO处理。( 也就是上述所说的 已经回滚了/未回滚 都要重新回滚)

对已经提交的事务队列中的各个事务进行REDO处理（ 也就是如果已经提交的了就要 重做）