9i新特性之四缩小非计划当机时间
了解哪些参数控制了
数据库实例崩溃的修复时间，并且知道9i数据库如何做实例崩溃恢复是这篇文章的目的，主要参考9i new feather，加入自己的理解，可能理解得不好，请大家指正。另外基础性的东西往往有些枯燥大家自己根据兴趣选择吧！
概论
非正常当机时间对业务的影响非常大。
oracle9i增加了很多减少当机时间的特性。
----快速recovery。
----减少任何故障对最终用户的影响。
-------------------------------------------------------------------
如何实现最小的i/o recovery
如果要减少非计划当机时间，恢复时间必须降到最低。而恢复过程中i/o操作的数量直接影响着
数据库的恢复时间。控制崩溃恢复时间的两个基础是
--读出redo log变化信息的时间
--读，更改，写这些变化所影响的
数据块的时间。
-----------------------------------------------------------------
..
oracle9i介绍了一个双通道实例或者崩溃恢复来缩减恢复时间。
这里介绍的双通道恢复不能用于介质恢复，这个特性只用于实例或者崩溃恢复。
如何最小化i/o恢复
日志文件经常包含在发生错误时不是脏块的变化
数据块。在
oracle9i,日志里增加了显示哪些块已经被成功写到磁盘的信息，在进行恢复时这些块将不会被操作，因此总体恢复时间将被缩减。这个特性不需要dba进行任何操作和配置。
---------------------------------------------------------------
想约束恢复一个崩溃所需要的时间，有两个时间因素必须控制好：
1:读log file所需要的时间.这依赖于日志文件设备的
数据传输速率,和恢复过程中需要读的日志数量.
2:在崩溃时在buffer cache中的已经被修改的
数据块的读写时间.这依赖于限制cache中被修改而不写入data file中的块的数量,使这个数量符合在你需要的恢复时间内能够读写的文件数量.
日志文件中很有可能记录了一部分在崩溃时buffer中的一些虽然已经被改变,但并不是脏块的纪录.这些
数据块已经在崩溃前成功的写入磁盘了.在恢复过程中不需要再对他们进行读和检查操作，这将可以节省大量时间.
新特性中,恢复时需要读log两次,第一次找到哪些块需要恢复,第二次恢复那些需要恢复的块.第一次的连续读非常快,相对于以前的方法,这些额外增加的时间是非常少的.
----------------------------------------------------------------------
fast-start time-based recovery limit
在恢复的时候，
oracle9i实例重演从checkpoint redo byte address
(checkpoint RBA))开始的所有变化，checkpoint RBA是存放在controlfile里的，需要recovery时,checkpoint RBA决定了重做日志流内开始应用recovery的位置。
提前checkpoint RBA的位置能够减少recovery time.为了提前checkpoint RBA，buffer cache里的脏块必须被写到
数据文件里。这个操作就是检查点操作。但是相应的过分频繁的检查点操作会影响
数据库性能。所以我们必须考虑如何取得性能和恢复速度的平衡。
-----------------------------------------------------------------------
fast-start time-based recovery limit
特点：可以设置很多的不同维护级别，包括恢复
数据库的时间范围。
DBA必须能够可靠的设置一个用来恢复
数据库的时间限制
oracle9i引入了基于时间点的快速恢复，这个属性允许dba指定一个多少秒内恢复
数据库的目标。
oracle9i实例自动计算来设定合适的内部参数，以达到指定的目标。现在设置秒级的恢复时间限制非常容易，以前这项工作非常困难而且准确性也很差！
-----------------------------------------------------------------------
基于时间点的恢复限制
前面我们提到了恢复时间取决于读取log files的时间和处理需要恢复的
数据块
的时间。
其中参数log_checkpoint_interval设定了恢复过程中将要被读的重做记录的数目。fast_start_io_target控制了需要被恢复的
数据块数目。然而，DBA可以通过单独设置参数来设置基于秒级的恢复时间限制。LOG_CHECKPOINT_TIMEOUT限制了上一检查点和最近的重做记录之间的秒数。但他对于设置恢复时间限制来说都是不够精确的！
新参数fast_start_mttr_target允许DBA指定
数据库进行崩溃恢复需要的秒数。
实际上这个参数被转化为设置参数FAST_START_IO_TARGET,LOG_CHECKPOINT_INTERVAL两个参数。这个特性大大简化了限定
数据库恢复时间，并增加了准确性。ast_start_mttr_target是一个动态参数，可以在线修改。例如：
alter system set fast_start_mttr_target =60;
在一个单实例
数据库配置中fast_start_mttr_target的值是一个估测的崩溃平均恢复时间。在rac里。最坏的情况下，实例崩溃恢复时间是所有的在open
(read/write open)状态的实例的fast_start_mttr_target参数值的和。但是实际的恢复时间会少一些因为初始化和文件打开只需要做一次。
然而，有一种情况下，在rac环境中，恢复时间会更少。因为一个失败的单实例
会被其他的已经打开的实例恢复到正常状态。需要失败恢复去覆盖rac中所有实例
的情况是一种比较极端的，很少发生的事情。 参数fast_start_mttr_target的范围是0-3600的一个整数。0是默认的，这表示恢复时间不是由这个参数来控制的。推荐大小取决于sga的大小。
数据库的启动，取决于很多变化的因素，包括维护级别协定。我们发现恢复时间随着维护级别的偏重于不影响性能的变化，恢复时间线性增长。
性能下降可以通过察看检查点后额外增加的块数目检测到。这些块作为一个严格限制恢复时间的结果。检查点统计被存放在statspack的输出中，也可以在v$instance_recovery视图中查到（列为ckpt_block_writes).
在实例恢复时，
oracle9i实例o重演以检查点重做字节地址为起始的变化。
推进检查点位置能够控制恢复时间？检查点的推进由四个参数控制。
– DB_BLOCK_MAX_DIRTY_TARGET
– FAST_START_IO_TARGET
– LOG_CHECKPOINT_INTERVAL
– LOG_CHECKPOINT_TIMEOUT
DB_BLOCK_MAX_DIRTY_TARGET：指定了buffer cache中dirty
buffer的最大数目。
FAST_START_IO_TARGET:指定了需要恢复的
数据块数目，9i之前，这个参数控制了将要被读和写的
数据块的数目，在双通道恢复中，这个参数等于需要被恢复的
数据块数目。
LOG_CHECKPOINT_INTERVAL：指定检查点和redo log结尾中间最大的重做记录数目。
LOG_CHECKPOINT_TIMEOUT：指定了检查点处的重做记录多少秒开始写入。
注意：就算没有任何参数限定，检查点