在上一篇文章数据库事务的实现（一） 故障恢复 （undo日志）中，我们介绍了undolog在数据恢复中的应用，这一篇文章仍会继续介绍undolog，但会深入介绍使用undolog进行数据恢复。
上一章的结尾我们留下了一个问题，就是在上一章所介绍的模型中，恢复管理器必须要通过全篇扫描整个undolog进行日志恢复，这样做显然是没有太大必要的，因为系统中断肯定是在最后几个事务受到影响，前面的事务应该已经完成commit或者rollback了，不会出现abort的情况，那我们如何知道哪些事务受到了影响呢，如果我们知道了哪一些事务受到了影响，那我们就可以不用全篇进行扫描，而仅仅扫描很小的一部分就可以了。下面就介绍下，数据库如何知道哪些事务受到了影响，数据库为了得到这个目的，引入了检查点（checkpoint）这个概念。
checkpoint 检查点
checkpoint，即检查点。在undolog中写入检查点，表示在checkpoint前的事务都已经完成commit或者rollback了，也就是检查点前面的事务已经不存在数据一致性的问题了。那这个checkpoint如何去实现呢。其实实现的机制很简单，就是周期性的往undolog里面写入。当然这个写入肯定不是随随便便的往里写，在往里写的时候，肯定要检查前面的事务是否完成。
这个时候就会带来一个问题，因为数据库是一直在运行的，也就是事务是在不断启动的，同时可能有n个事务已经处于开始状态。而在检查点往里写的时候，可能又有新的事务启动了，如果让检查点一直等到没有新的事务启动而且前面所有的事务又都提交过了估计很难，那基本检查点就不用往里写了。所以，在这种情况下，只能是在检查点往里写的时候，停止接受新事务，等待已启动的事务提交完毕，然后检查点写入完毕。然后继续接受新事务。类似于这样： 例如，现在有T1 T2两个事务，则undolog中写入：
| start T1 |
| start T2 |
这时到了检查点的周期，要往里写入检查点了，就得等到T1,T2全部提交完毕，然后写入检查点chkpoint。也就是如果现在有一个T3要开启，是无法开启的。系统处于夯住状态。写入完后，开启T3，日志记录如下：
| start T1 |
| start T2 |
| end T1 |
| end T2 |
| chkpoint |
| start T3 |
这时候，如果系统挂掉了，故障恢复管理器会从undolog的尾部向前进行扫描，扫描到checkpoint后，就不会往前扫描了，因为前面的事务都已经提交过了，不存在数据一致性问题。所以只需要从checkpoint开始重做即可。
这样固然是好，省掉了需要undolog从头开始扫描的麻烦，但是这样做的缺点也很明显，那就是在写入checkpoint的过程中，系统是出于夯住状态的，所有的写入都要暂停。那能否有一种更好的方法既可以写入checkpoint又不需要系统暂停呢，必须的，当然有，这就是下面要讲的非静态检查点。
非静态检查点
非静态检查点是相对于静态检查点而来的，上文中所提到的就属于静态检查点，因为在检查点写入的同时，系统是不能写入的。而非静态检查点的引入，就是要解决这个问题。
非静态检查点的策略是在写入chkpoint的同时，会记录下当前活跃的事务。比如，当前状态下，T1和T2都是活跃状态，那么undolog中会被写入start checkpoint(T1,T2),这时整体系统仍然是正常写入的，也就是说在这条log写入后，仍然可以继续开启其他事务。当T1,T2完成后，会写入end checkpoint的记录。例如如下记录：
| start T1 |
| start T2 |
| start checkpoint(T1,T2) |
| start T3 |
| end T1 |
| end T2 |
| end chkpoint |
| start checkpoint(T3) |
| end T3 |
| end chkpoint |
上面这个日志记录就是，在T1,T2开始后，undolog中写入了start checkpoint(T1,T2)的检查点，而这时仍然是可以接受其他事务的开始的，这时有了T3事务的开启。
通过这种机制，可以有效避免在检查点写入时需要停掉服务的弊端，但现在问题又来了，这样写检查点固然是好，但恢复管理器如何通过这样的undolog去进行数据恢复操作呢？因为，如果检查点是静止的，那找到checkpoint后，就不必再往前找了，而现在不一样了，因为找到end checkpoint后，前面仍可能有未完成的事务，那这时数据恢复是如何恢复的呢？
在这种情况下，数据库宕机后，恢复管理器仍然会从尾往前进行扫描undolog，如果遇到了“end chkpoint”，这时并不代表checkpoint前所有的事务都已经提交了，但我们可以知道，所有未提交的事务都是在上一个start checkpoint之后，所以会继续往前找，一直找到start checkpoint,找到start checkpoint后，比如是start checkpoint(T1,T2),因为先前已经找到了end chkpoint，所以T1,T2这两个事务已经可以保证数据一致性了，需要重做的就是在start checpoint(T1,T2)到end chkpoint间的这一些非T1，T2事务，这些是需要重做的，所以要把这些进行重做。
还有另外一种情况，就是恢复管理器在扫描时，先遇到了start checkpoint(T1,T2)的日志，在这种情况下，我们首先知道了T1,T2或许是未完成的事务，那这时需要在start checkpoint之后找到是否有某个事务的end语句，如果有，说明这个事务是完成了，如果没有，就说明没有完成，那就要从check point再往后寻找，找到这个事务的start，然后从start之后往后重做。说得比较罗嗦，我们上个例子来说明下这种情况。
例如，数据库宕机后，开始扫描undolog，得到以下片段：
| start T1 |
| start T2 |
| start checkpoint(T1,T2) |
| start T3 |
| end T1 |
这时，恢复管理器拿到这个片段后进行扫描，在遇到end chkpoint前遇到了start checkpoint(T1,T2)，这说明了，T1,T2是可能未完成事务的，而且在这之前还遇到了T3的start，没有end T3，也没有任何T3的检查点的开始，这说明了T3一定是未完成事务的，所以T3一定是要重做的。先前为什么说T1,T2是可能未完成事务的呢？因为遇到了start checkpoint(T1,T2),没有遇到end chkpoint，并不代表T1和T2就一定是未完成的，可能有一个已经commit过了，因为两个都没有commit，所以才导致了没有end chkpoint，所以这时找start下面的日志，发现了“end T1”，说明了T1的事务是已经完成了的。那只需要找T2的开启然后开始重做就可以了，然后就通过start checkpoint(T1,T2)再往上找，找到了start T2，然后开始重做T2，也就是这个日志里，T2和T3是需要重做的，然后重做掉。 （注：刚才先说了做T3，然后有说了重做T2,并不代表真正的顺序就是这样，实际上恢复管理器是先分析出需要重做的事务，然后一块做掉的。)
好了，文章写到这，该结束了，对于undolog的叙述也就到这了。希望可以对大家有所帮助。
下一篇文章，我们来描述redolog，undolog和redolog都是数据库故障恢复的机制，但和undolog的实现及原理不太一样。下一篇我们将介绍到。
本文来自于我的个人博客 http://www.log4myself.info/archives/293
bitsCN.com