22 数据库恢复技术

更新有两种 , deferred update , immediate update .
前者会在提交前将修改放在内存中，直到提交才更新database，这样一旦在提交前失败，就不需要undo; 若提交后挂了，需要 redo

后者是在提交前，可能某些更新就到盘了，这样在一般情况下，undo,redo它都需要；
它的一种变种是在提交前都到盘，若提交失败需要undo，若提交成功后挂了不需要redo（数据都在盘了）

undo, redo 操作得是幂等的，如果在恢复期间再次crash，重启时再进行恢复的结果应该要和只crash一次的情况一样

每个buffer有dirty, pin bit

有两种方式flush 更新块到磁盘，一种是in-place updating(非常常见)，原位更新，一种是shadowing，写更新块到单独的地方（这样就维护了多个版本，甚至 log 都不是很需要）;
更新前的value 叫 before-image , 更新后的value 叫 after-image

WAL

DBMS cache中包含data file block ,index file block ,log file block

如果使用原位更新，则需要 log for recovery
恢复算法必须 保证在 BFIM 被 AFIM 覆盖前，BFIM 已经刷到了log entry里

no-steal: 提交之前，更新的buffer 不写到盘（作者也说了deferred update scheme 和 no-steal 是一致的）； (它不需要undo，因为是在提交后才刷数据，如果刷数据时崩了只需redo，提交时崩了，由于数据没写，就不需要undo)

force: 提交之前 all updated page written to disk，意味着redo不需要（提交失败时只需undo，提交成功时不需要担心还有数据没有flush）； 问题是提交时间变长 ( force 与 immediate update 时机不一样，前者说的是提交前所有的更新刷盘，后者说的是更新过程中逐渐刷盘？？)

典型模式是 steal + no-force
no-force好处在于节省大量I/O，特别是在多个事务都在更新一个page时，不至于每次更新都flush一次