实例恢复时间

MTTR(实例平均恢复时间)是许多服务级别协议的一个重要的部分。实例恢复能够保证
不造成损坏，但是在数据库能够打开之前需要耗费大量时间来完成实例恢复的前滚操


作。这个时间取决于两个因素：需要读取的重做数，以及应用重做时需要在数据文件


上完成的读/写操作数。这两个因素都受到检查点的控制。
检查点保证了在某个特定的时间，DBWn进程已将构成一个特定系统更改号(SCN)的所


有数据变更都写入数据文件。在一个实例崩溃事件中，只有SMON进程需要重演从上一


个检查点位置开始生成的重做。无论是否被提交，在这个检查点位置之前所作的全部
变更都已写入数据文件。因此，不需要重新构造该检查点位置之前的撤销数据，回滚


需要使用的这些数据已经存在于磁盘上的撤销段内了。
  检查点位置越近，实例恢复就越快。如果检查点位置是最近的，那么不需要前滚，


此时就可以立即打开实例并直接进入回滚阶段。不过实现这种操作的代码很大。为了


前移检查点位置，DBWn进程必须将变化的数据块写至磁盘。过多磁盘I/O会削弱数据


库的性能。但在另一方面，如果不频繁的使用DBWn进程，那么在实例崩溃后，SMON就


必须处理数千兆字节的重做以及在数据文件上执行数百万次的读/写操作，实例失败后


的MTTR可能会延长到数小时。
    在Oracle9i后，引入了一个新的参数:fast_start_mttr_target,这个参数使得


对实例恢复时间的控制变得十分容易。我们以秒为单位制定该参数，Oracle随后将确


认DBWn进程在实例崩溃后能够以足够快的速度将数据块写至磁盘，从而使恢复操作不


会超过制定的秒数。因此，设置的fast_start_mttr_target参数值越小，DBWn进程


将会更努力的尝试最小化检查点位置与实际时间之间的间隔。不过需要注意的是：这


只是一个目标，如果设置了一个不且实际的较小值，那么DBWn进程无论如何也不可能


达到要求。另外，Database Control提供了一个MTTR顾问程序，这个顾问程序可以让


您确定实例失败后需要的恢复时间。从v$instance_recovery视图中也可以获得这些


信息。