数据库恢复

数据库恢复

恢复重要在于出现问题前冗余，而不是出问题之后的操作。

数据库工作的物理存储结构：

数据库恢复面临的问题：内存中的数据没写回disk

例子：
起始A=1000，B=2000
A向B转账50.
dist-》buffer-》work area，数据再workarea操作，并且从workarea向buffer写回结果。
buffer的A写入disk，A=950，但是B还没写入内存挂掉了，那么事务是无法简单恢复的。

即时写回和延迟写回
延迟写回只有在commit后才会写回disk。
即时写回是在内存中执行完操作后按照系统规则和实时状态决定是否立即写回disk。

先写日志再更新
上面的例子的执行流程可以看下面的:

如果执行失败（没有commit就断电了），需要undo撤回，即执行<T0,A,1000><T0,B,2000>
undo具有幂等，只将变量改为最终状态1000.
如果commit后断电了，但是没写入disk，那么需要执行redo，即重复做日志
<T0,A,1000,950>,<T0,B,2000,2050>

检测点checkpoint

在检测点之前的脏数据都写回到disk完全生效，在log上面打上checkpoint。
需要恢复时候就只需要处理checkpoint的数据。

对于上图，不管T1，数据恢复只管T2，T3,T4.
一个恢复的完整过程：

恢复中的undo和redo执行

恢复的详细过程：

1. 找到最近的checkpoint，建立undolist。
2. 从日志前到后遍历， 检查点之后的事务操作redo。
3. 检查点之后开始的事务操作添加到undo-list。
4. 提交或者abort（流产）的事务从undo中去掉。
5. 从日志后到前遍历，遇到undo-list中记录的事务操作undo。
6. 在恢复过程中需要在日志中记录恢复的操作。
   简单来说，就是从前往后所有操作redo一遍，从后往前没有提交的事务操作undo一遍。
   就是在checkpoint后，没有提交的事务undo（完整地undo，undo到这个事务的start，可能会越过多个checkpoint，将这个事务完整地undo），提交的事务操作redo。