事务-----故障恢复

• 事务包含两大部分-1、并发控制2、故障恢复。

• 故障分为事务故障（影响范围为发生故障的事务）系统故障（整个数据库 ）介质故障。常用的恢复故障的方法为重做或者撤销。关于介质故障的恢复是通过数据库备份以及运行日志来实现。介质故障后，需要将转储点后的备份文件+转储点之后的文件需要运行日志来恢复。

• 系统故障的恢复：主要是数据库系统维护的运行日志。数据库在进行写操作的时候，首先需要在系统日志里面写操作日志，再进行buffer pool的操作。DBMS运行日志会设置检查点，使得出系统故障后可以从最近的checkpoint点来恢复。那具体应该怎么恢复呢？对于checkpoint 之前已经结束的事务不作考虑，对于checkpoint之后开始或者结束的事务：如果故障点之前结束重做事务，如果故障点之后结束事务，撤销事务。

• 数据库缓冲区策略：Force 事务commit时候必须从DB buffer 写入磁盘中。 steal:事务commit之前可以写入到磁盘中。 No steal 不允许事务commit之前将内存中的数据写入到磁盘中。No force 可以在commit之后一段时间再将内存写入磁盘。 最常见的是NO force / steal 因为性能高，灵活。

• 2021-1-22:追加：
  @start
  Force 其实就是在commit之前必须将更新写入磁盘。（make sure every update is on disk before commit）
  force 的优点是由于在commit之前是肯定是从Buffer pool 固化到磁盘上了，所以不存在redo的问题，只需要undo。缺点是性能下降。
  No steal 是指不允许将buffer pool未提交的事务涉及的数据覆盖到disk 已经提交数据上，（dont allow buffer-pool frames with uncommitted updates to overwrite committed data on disk）优点是不需要undo,只需要redo 因为只有提交后的frame才能被写入disk。
  @end

• 日志：只能追加日志操作记录的文件。有undo 日志 redo日志 undo/redo 日志。
  
  现在一般数据库为了性能考虑都将采用No force 和steal。之前我也想不通既然事务提交之前已经写入磁盘，而且提交时能够保证写入磁盘的数据都是已提交的，那么为什么还要故障恢复呢？？？？ 其实我假想的是一种最保守最慢的数据库缓冲区管理策略，由于采用了No force 和 steal 策略，可能存在已经提交的事务相关数据未写入磁盘，也可能存在未提交事务相关数据写入磁盘的情况。所以当故障发生时，需要根据日志文件进行REDO和UNDO;
  

• Undo型日志的恢复：如果故障发生于commit之后由于output 在commit之前已经完成，所以可以跳过这种情况的处理，如果故障发生于commit之前，要利用<T,X,V>进行Undo。（次序从后向前）

• Redo型日志的恢复：如果故障发生于output之后，显然这种情况应该忽略掉，因为No Froce的情况下，output发生时，必然已经提交。故障发生在output之前时，应该利用<T,X,V> 进行Redo;

• 对于Undo Redo 结合型日志,则需要从前向后redo,从后向前Undo;