如果数据库不用考虑数据恢复，对我们这些做数据库的人来说，日子也许将变过美好很多。

　　没有一种软件会象数据库这样，需要面对如此恶劣的环境。你需要考虑各种可能的错误和故障，例如系统断电、磁盘损坏、甚至是地震火灾。而给你的目标非常明确：不论发生何种故障，数据都不能被丢失，你可能觉得这有些小题大做，可对于许多商业应用（如银行、火车订票系统等）来说，这只不过是最基本的要求。

　　要保证每一步操作都不会丢失，既无必要，也无可能（除非你能发明一种和硬盘一样大，和内存一样快，同时断电时数据不丢失的东东）。因此同并发控制中一样，数据库同样也利用了事务的概念。事务是这样一组操作，这组操作要么都做，要么都不做（我们通常把这叫做事务的原子性）。而当你决定结束一个事务时，你可能会选择：是提交（COMMIT）这个事务，还是应该滚回（ROLLBACK）它。如果你选择提交，那么你在这个事务中所做的全部修改都会被存入数据库中，如果这个数据库系统足够强壮，它将保证：只要事务提交完成，不管今后发生何种故障，事务所做的修改都不会丢失。如果你选择滚回，那么系统将回到事务开始的状态，你在该事务中所做的所有修改都将丢失。如果在事务运行当中，系统发生了任何故障，你会期望它的结果应该和你滚回这个事务一样。

　　数据恢复的本质是数据的冗余，在众多的冗余手段中，日志（log）也许是我们最常使用的数据恢复技术（尽管我们还有许多其它的选择，如影子页面等）。在我们对数据库进行修改之前，系统会将数据修改前的影象（前项）和你要修改的数据影象（后项）保存在日志当中。在这个过程中，有两点需要保证。一是日志必须先于它对应的修改被写入数据库，我们把这叫做先写日志（WAL）协议，这很容易理解，想象一下，如果修改被先写入数据库，而系统在日志被写入之前崩溃了，那么它将无法把该数据恢复到开始的状态。二是在事务提交之前，必须将它的日志写入数据库。否则，系统无法保证后续的故障不会丢失该事务的修改。我们将不能实现我们在前面对用户所做出的承诺。