fast recovery

fast recovery是INFORMIX-OnLine的一种机制，允许OnLine系统从断电或UNIX崩溃一类故障中快速恢复。快速恢复不提供从介质故障中恢复的机制。
快速恢复的目的首先是恢复OnLine系统到最后一个检查点，在该检查点，系统在物理上一致。然后，利用逻辑日志文件中从该检查点开始后的事务记录前滚所有事务，实际上是对该检查点后开始的所有的事务均重做一遍，最后，回滚所有发生故障时刻未完成的事务。

这样的结果是所有数据库，由于发生故障时的事务或被完成或被回滚而处于一个一致状态。

快速恢复过程启动后，就没有办法停止。每当OnLine启动后，都会自动发生快速恢复过程。

如果你的OnLine系统以正常方式关闭，即通过onmonitor关闭或其它管理程序关闭，则在关闭之前，最后一个操作是一个检查点操作。这意味着，物理日志将是空的，而逻辑日志文件的最后一条记录是检查点记录。

如果你的OnLine系统以正常方式关闭，系统消息日志文件中的最后一项会指示OnLine系统已经正常关闭。

如果OnLine系统不是以一种可控制方式停机，则系统停机前最后一个事件将不是检查点，结果是，物理日志文件可能非空，逻辑日志文件的最后一条记录也不是检查点记录。在这种情况下，重新启动OnLine后，快速恢复过程将做许多工作。

 

如果消息日志文件的最后一条记录没有表明OnLine的停止操作，也能确信OnLine系统不是正常关闭，因此，当OnLine重新启动时，快速恢复将恢复系统至一个明确状态。

 

快速恢复过程的第一步是从物理日志文件中恢复前映像。如果物理日志文件为空，则快速恢复的第一步即告完成。但是，如果物理日志文件非空，需要采取进一步措施。

快速恢复过程的第一步是读包含在物理日志文件中的前映像并将它们写回到相应磁盘页。这保证了磁盘上的数据恢复到发生故障的前一个检查点状态。具体实施过程是：读物理日志文件中的前映像到共享内存，然后作一次检查点操作。这是恢复这些页的最有效方法，因为它允许清页线索作数据写操作。

当物理日志文件所有前映像处理完毕后，就完成了快速恢复的第一步。

这一步的恢复操作是必须的，因为共享内存中修改页可能在检查点操作之前刷新到磁盘上。该步保证了即将开始的前滚过程是在数据的一致状态下进行的
快速恢复过程的第二步是在逻辑日志文件中找到最后一个检查点记录，该记录的位置记录在系统保留页中。当找到该记录后，逻辑日志文件中从此记录开始的所有事务均被前滚，实际上是把自最后一个检查点以来所有对数据库的修改重新做一遍。

当自上次检查点以来所有逻辑日志记录重做完以后，快速恢复的第二步即告完成。

快速恢复过程的第三步是回滚逻辑日志文件中所有没有提交的事务。这保证了在发生故障时所有提交的事务均被完成，没有提交的事务均被回滚。所有发出了COMMIT或ROLLBACK WORK语句的事务均保留。

为完成全部回滚，有可能读最后一个检查点以前的逻辑日志文件记录(一个事务在活动期间完全有可能跨越多个检查点记录)。

当快速恢复的第三步完成后，所有提交的事务均被恢复，而所有未提交的事务均被回滚，系统的启动过程可以继续下去，使OnLine系统处于静止状态。

在快速恢复完成以后，所有在发生故障时完成的事务都将被恢复，而所有没有完成的事务均被回滚，这保证数据库恢复到一个完全一致状态。

 

应该注意，快速恢复只能恢复记录在逻辑日志文件中的事务。如果使用缓冲日志模式，则完全有可能一个提交的事务并未将其事务记录写到逻辑日志文件上(这些记录还在逻辑日志缓冲区中)。在这种情况下，当发生故障时，包含在逻辑日志缓冲区中的事务将丢失。因此快速恢复并不能恢复一个应用程序认为已经提交的所有事务。

 

必须注意到，如果一个OnLine数据库没有使用日志模式，则逻辑日志文件中没有事务记录，故也不能进行前滚操作。既然不能关闭快速恢复，这就意味着，如果一个没有使用日志模式的OnLine系统发生故障，系统只能恢复到其最后一个检查点状态。因为对数据库无事务操作，快速恢复的第二步和第三步不可能实现。换句话说，自最后一次检查点以来对数据库的所做的修改都会丢失。

在快速恢复过程中，每个步骤有关的信息均会记录在OnLine消息日志文件中。

记录快速恢复过程的第一步，即物理恢复过程的消息行表明，从物理日志文件中恢复了多少页的前映像；而记录其第二步和第三步即逻辑恢复过程的消息行表明，恢复了多少个事务，回滚了多少个事务，多少个事务仍被打开，以及不能获得锁的事务个数(后两种情况仅适用于INFORMIX-TP/XA或分布式环境)。另外，从上述信息中无法精确决定哪些事务被恢复了，哪些事务被回滚了 。如果需要得到这些信息，可以使用onlog实用程序来决定哪些事务受到影响。