走近数据恢复

我常常在想，如果数据库不用考虑数据恢复，对我们这些做数据库的人来说，日子也许将变过美好很多。
　　没有一种软件会象数据库这样，需要面对如此恶劣的环境。你需要考虑各种可能的错误和故障，例如系统断电、磁盘损坏、甚至是地震火灾。而给你的目标非常明确：不论发生何种故障，数据都不能被丢失，你可能觉得这有些小题大做，可对于许多商业应用（如银行、火车订票系统等）来说，这只不过是最基本的要求。
　　要保证每一步操作都不会丢失，既无必要，也无可能（除非你能发明一种和硬盘一样大，和内存一样快，同时断电时数据不丢失的东东）。因此同并发控制中一样，数据库同样也利用了事务的概念。事务是这样一组操作，这组操作要么都做，要么都不做（我们通常把这叫做事务的原子性）。而当你决定结束一个事务时，你可能会选择：是提交（COMMIT）这个事务，还是应该滚回（ROLLBACK）它。如果你选择提交，那么你在这个事务中所做的全部修改都会被存入数据库中，如果这个数据库系统足够强壮，它将保证：只要事务提交完成，不管今后发生何种故障，事务所做的修改都不会丢失。如果你选择滚回，那么系统将回到事务开始的状态，你在该事务中所做的所有修改都将丢失。如果在事务运行当中，系统发生了任何故障，你会期望它的结果应该和你滚回这个事务一样。
　　恢复的本质是数据的冗余，在众多的冗余手段中，日志（log）也许是我们最常使用的技术（尽管我们还有许多其它的选择，如影子页面等）。在我们对数据库进行修改之前，系统会将数据修改前的影象（前项）和你要修改的数据影象（后项）保存在日志当中。在这个过程中，有两点需要保证。一是日志必须先于它对应的修改被写入数据库，我们把这叫做先写日志（WAL）协议，这很容易理解，想象一下，如果修改被先写入数据库，而系统在日志被写入之前崩溃了，那么它将无法把该事务恢复到开始的状态。二是在事务提交之前，必须将它的日志写入数据库。否则，系统无法保证后续的故障不会丢失该事务的修改。我们将不能实现我们在前面对用户所做出的承诺。
　　我们继续上文的讨论，看看我们到底有哪些故障需要应付。
　　首先是应用故障，例如用户不小心错删了一张表，或者应用破坏了完整性约束。这种故障的恢复非常简单，对于前者，你可以显式地滚回事务（利用日志的前项），如果你不小心提交了事务，那么问题就麻烦了，系统也许只能把它当作介质故障（利用备份）来恢复了；对于后者，系统会强迫把该事务滚回。只要数据库还在运行，在系统看来，事务的滚回与其它正常操作并没有什么区别。
　　然后是进程故障，假如在系统运行时，一个client崩溃了，或者网络断了（通常服务器无法区别这两种状态）；或者服务器端的某个进程死了。这时我们恐怕得为系统配置一个监视进程，由它来定期地检查系统状态，恢复或清除失败的进程（连接），同时把对应的事务滚回。我们会希望这个监视进程是所有进程的父进程，因此假设连它也死了，我们就能把这种情况归结到后面将要讨论的系统故障。
　　接着是系统故障，假如系统因为内部错误（例如数据库或操作系统含有bug），或者发生断电。这时缓冲区里的数据全部丢失，但幸运地是磁盘上的数据还在。因此系统在重新启动（RESTART）后，首先重做所有事务的修改（利用日志的后项），这就让数据库回到了发生故障时的状态，这时再将所有在这一点上未提交的事务滚回就完事了。注意这一过程是自动完成的，你完全不需要去关心它。
　　再接着是介质故障，假如磁盘出现了坏磁道，或者整个磁盘报销了。这时上面的数据肯定已经丢失了。由于介质故障只能在你试图再次存取磁盘时被发现，而这时故障可能早已发生。因此对介质故障的恢复需要你的参与才能完成。你必须定期地备份（BACKUP）数据库，这样，当介质故障发生时，你可以先用备份重新覆盖整个数据库（RESTORE过程），然后利用日志重做从备份那点到当前的数据库的更新（ROLL-FORWARD过程），接下来的事情就和系统故障完全一样了。你可能会问，那要是日志也坏了怎么办呢？没办法，鸡生蛋、蛋生鸡，总得有个头吧。所以你最好祈祷日志不要坏，为了保证这一点，你应该对日志文件进行镜象，或者干脆用RAID。
　　除了这种恢复方式，我们还有一种叫做逻辑恢复的方式，也就是利用我们常常在用的IMPROT/EXPORT工具对数据进行备份/恢复。当然我们只把它看作是介质故障恢复的一种辅助形式（也许它更适合于恢复我们前面说的那种应用故障），因为你只能把数据恢复到你备份的那一点。
　　最后是灾难，象发火灾、被人黑了什么的，这时整个系统可能被完全破坏。你当然仍然可以对数据库进行备份，然后把备份（磁盘）放到另一个安全的地方，但这样做，备份以后数据库所做的修改可能就永久丢失了。一个更为稳妥的办法是我们在远程建立一个备份系统，所有在本地产生的日志同时也送往这个远程系统，为了防止网络发生故障，本地与远程系统之间应该同时建立几条相互独立的网络连接。这听上去好象有点超前，可实际上许多关键应用早就用上了。
　　应该明白的是，恢复毕竟是一种非常耗时的工作，特别是进行后三种故障的恢复时，数据库对用户不可用。而这对象银行这样的部门来说，损失实在太大了。因此在很多情况下，我们只把恢复看作是最后的一道防线，我们希望最好永远也别需要用到它。因此现在就出来了各种各样的容错设备，象RAID、双机系统什么的，它们会把故障发生的概率降低到一个实际上可能永不发生的程度。