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：指定了检查点处的重做记录多少秒开始写入。
注重：就算没有任何参数限定，检查点推进也会被最小日志得100%大小所控制。即：oracle强制这一行为是通过确认检查点
和最近重做记录之间的重做块的数目小于最小的日志的100%,假如参数log_checkpoint_interval的值小于最小日志的100%,那么最小日志的大小将不再影响检查点行为。
-------------------------------------------------------------------------------------
参数变化
db_block_max_dirty_target参数已经被去掉。
假如fast_start_io_target or log_checkpoint_interval被
指定，他们会自动覆盖由fast_start_mttr_target参数计算出来
的值。
log_checkpoint_timeout没有改变。
新参数fast_start_mttr_target被内在的解释成两个参数:
fast_start_io_target和log_checkpoint_interval.假如这两个参数没有显式的指定,计算值将生效.
假如fast_start_io_target或者log_checkpoint_interval被显式指定,这个内部计算的值将被忽略,指定的值将替代计算值.
利用规则计算一些任务比如:初始化,文件打开,读日志,从数据文件中读取数据块,写数据块到数据文件中,这是一个适应性的规则,首先用内部计算来评估这些操作,然后当系统监测到可利用的现实数据后,会对这个数据进行替代.因此这个评估是比较精确的,因为服务器对自己的环境和独特的i/og更了解.因为人工计算完成这些操作所需要的时间,并通过这些来计算控制恢复时间的参数是一项复杂的任务,因此这个特性大大简化了任务,并增加了实例恢复时间的准确性.
视图v$instance_recovery的变化
增加了3个新列.这些列取代了以前的仅仅为了版本兼容而留
下列的信息.
新列是:
TARGET_MTTR:用户设置的参数FAST_START_MTTR_TARGET的值.
ESTIMATED_MTTR:根据目前脏块数目和日志块数目,评估的现在进行恢复所需要的时间.
CKPT_BLOCK_WRITES:检查点写完的块数目.
oracle9i实例最初用在恢复时对i/o速率的内部评估来计算这些参数的值.通过系统监测,计算出实际的i/0速率,并用这些信息来为以后的恢复做更精确的计算.因此,恢复时间评估会越来越精确.
oracle9i实例调整检查点速率来适应参数的目标值,然而这不是一个硬指标,因此很可能评估的恢复时间和目标设置不等. 视图v$instance_recovery是用来监测检查点以及检查点对恢复的影响.每30秒,oracle9i数据库计算一个目前恢复需要
时间的评估,并将这个值放入v$instance_recovery视图,这答应dba检测现时的恢复评估时间,并跟fast_start_mttr_target指定的目标值进行比较.
因为不必要的检查点的产生,设置一个非常小的系统恢复时间将会对性能产生负面影响,为了帮助治理员监测这个参数设置较小时对数据库的影响,这个视图也显示了额外的因为检查点引起的数据库写入操作,它是列CKPT_BLOCK_WRITES.
