--交易型数据库事务恢复研究
------------------------------2014/05/22
DB2 日志循环，如果事务太长，活动日志（未提交lowTranLSN，未刷入磁盘minBufferLSN之前）不能能覆盖，报错：没有日志可写入，不能被覆盖。
这是由于DB2的实例恢复是从min(minBuffLSN,lowTranLSN)开始的，就是说最早未提交的事务LSN和最早还没刷入磁盘的LSN比较，哪个早从哪个开始恢复，在min(minBuffLSN,lowTranLSN)之后的日志，全部都是活动日志，不可以被覆盖。
PS: 没有undo表空间和MVCC就是很惨~~~
ORACLE 日志循环，没有DB2的问题。这是由于ORACLE标记检查点之后的日志，都是inactive状态，可以被覆盖，只要保证日志在被覆盖前，检查点更新到被覆盖的日志LSN后，保证此日志中的操作都被持久化到磁盘中就可以了，不关心该事物是否提交。
在崩溃恢复时，从检查点开始的地方开始重做redo。对于没有提交却写入磁盘的，ORACLE有undo。
undo阶段：smon扫描undo segment header的活动事务表，未提交的事务，对于undo来说显然都是活动的。将这些段回滚，显然都能过保证事务的一致性。
注意：如果有事务持续更新或删除操作，而不提交，那么回滚段中的事务都是活动的，不能被覆盖，导致回滚段一直扩展，会导致回滚段变的非常大。
MySQL Innodb的日志是环形写的，当写到日志的尾部，会重新跳转到开头继续写，但不会覆盖还没有应用到数据文件的日志记录，细节如何？？？
由于innodb也是有回滚段的，与oracle不用的是，innodb存储引擎级别的日志不能归档，只能循环使用。同样我们可以知道，MySQL只要保证innodb日志在被循环覆盖前，只要保证被覆盖的日志的操作都被持久化到硬盘中就可以了，也不关心事务是否提交。
崩溃恢复的过程与oracle一致。
所以当事务日志没有足够的空间剩余，快要去循环覆盖时，innodb也将进入“激烈刷写（Furious Flushing）”模式，这也是大日志文件可以提升性能的一个原因。
注意：虽然是循环日志，也能构造出一个空间剩余的概念，就是活动日志对整个日志大小的占比，如果快到100%，很显然剩余不足，innodb将激烈刷写buffer中的脏块。