首先是应用故障，例如用户不小心错删了一张表，或者应用破坏了完整性约束。这种故障的恢复非常简单，对于前者，你可以显式地滚回事务（利用日志的前项），如果你不小心提交了事务，那么问题就麻烦了，系统也许只能把它当作介质故障（利用备份）来恢复了；对于后者，系统会强迫把该事务滚回。只要数据库还在运行，在系统看来，事务的滚回与其它正常操作并没有什么区别。

　　然后是进程故障，假如在系统运行时，一个client崩溃了，或者网络断了（通常服务器无法区别这两种状态）；或者服务器端的某个进程死了。这时我们恐怕得为系统配置一个监视进程，由它来定期地检查系统状态，恢复或清除失败的进程（连接），同时把对应的事务滚回。我们会希望这个监视进程是所有进程的父进程，因此假设连它也死了，我们就能把这种情况归结到后面将要讨论的系统故障。

　　接着是系统故障，假如系统因为内部错误（例如数据库或操作系统含有bug），或者发生断电。这时缓冲区里的数据全部丢失，但幸运地是磁盘上的数据还在。因此系统在重新启动（RESTART）后，首先重做所有事务的修改（利用日志的后项），这就数据恢复让数据库回到了发生故障时的状态，这时再将所有在这一点上未提交的事务滚回就完事了。注意这一数据恢复过程是自动完成的，你完全不需要去关心它。

　　再接着是介质故障，假如磁盘出现了坏磁道，或者整个磁盘报销了。这时上面的数据肯定已经丢失了。由于介质故障只能在你试图再次存取磁盘时被发现，而这时故障可能早已发生。因此对介质故障的恢复需要你的参与才能完成。你必须定期地备份（BACKUP）数据库，这样，当介质故障发生时，你可以先用备份重新覆盖整个数据库（RESTORE过程），然后利用日志重做从备份那点到当前的数据库的更新（ROLL-FORWARD过程），接下来的事情就和系统故障完全一样了。你可能会问，那要是日志也坏了怎么办呢？没办法，鸡生蛋、蛋生鸡，总得有个头吧。所以你最好祈祷日志不要坏，为了保证这一点，你应该对日志文件进行镜象，或者干脆用RAID数据恢复。