FAST_START_MTTR_TARGET参数

1        什么是FAST_START_MTTR_TARGET

首先，什么是FAST_START_MTTR_TARGET。参数FAST_START_MTTR_TARGET是指允许DBA指定数据库进行崩溃恢复需要的秒数。MTTR（mean time to restoration）指平均恢复时间。

恢复时间取决于读取log files的时间和处理需要恢复的数据块的时间。参数log_checkpoint_interval设定了恢复过程中将要被读的重做记录的数目。 fast_start_io_target控制了需要被恢复的数据块数目。然而，DBA可以通过单独设置参数来设置基于秒级的恢复时间限制。 LOG_CHECKPOINT_TIMEOUT限制了上一检查点和最近的重做记录之间的秒数。但他对于设置恢复时间限制来说都是不够精确的！

所以Oracle10r2后有了FAST_START_MTTR_TARGET，实际上这个参数被转化为设置参数FAST_START_IO_TARGET,LOG_CHECKPOINT_INTERVAL两个参数。这个特性大大简化了限定数据库恢复时间，并增加了准确性。fast_start_mttr_target是一个动态参数，可以在线修改。例如： alter system set fast_start_mttr_target =60;

数据库的恢复有两个步骤，Cache Recovery和Transaction Recovery。首先进行Cache Recovery，相当于一个Rolling Forward的过程。即oracle会应用redo log文件中所有已经提交或在当机时还未提交的变化(因为所有变化在写入数据文件前都会先记录到redo log文件中)。然后进行Transaction Recovery，相当于一个Rolling Back的过程。即为了使数据库达到一致性要求，Oracle会回退undo tablespace（Oracle10g中取消了rollback segments，因为回滚段管理起来太复杂）中的所有未提交事务。

Oracle会周期性的记录检查点（checkpoint）。关于checkpoint：

“A checkpoint is the highest system change number (SCN) such that all data blocks less than or equal to that SCN are known to be written out to the data files. If a failure occurs, then only the redo records containing changes at SCNs higher than the checkpoint need to be applied during recovery. The duration of cache recovery processing is determined by two factors: the number of data blocks that have changes at SCNs higher than the SCN of the checkpoint, and the number of log blocks that need to be read to find those changes.”

因为checkpoint会促使后台进程DBWn将脏数据写入数据文件，所以频繁的checkpointing writes有利于大大缩短数据库的恢复时间。但如此频繁的写入操作也会降低数据库的运行性能。如上面所说，这个频度由参数FAST_START_MTTR_TARGET决定。当FAST_START_MTTR_TARGET >0时，将会激活Fast-Start Fault Recovery 功能。关于Fast-Start Fault Recovery：

“The foundation of Fast-Start Fault Recovery is the Fast-Start checkpointing architecture. Instead of conventional event-driven (that is, log switching) checkpointing, which does bulk writes, fast-start checkpointing occurs incrementally. Each DBWn process periodically writes buffers to disk to advance the checkpoint position. The oldest modified blocks are written first to ensure that every write lets the checkpoint advance. Fast-Start checkpointing eliminates bulk writes and the resultant I/O spikes that occur with conventional checkpointing.”

一旦FAST_START_MTTR_TARGET被设定成实际可行的值时，那么你的数据库的平均恢复时间会尽量达到该值设定的大小。但有几点需要注意：

1. 当你设定FAST_START_MTTR_TARGET时必须禁用或者删除FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT这三个参数。因为这三个参数将会和FAST_START_MTTR_TARGET互相干扰。
2. FAST_START_MTTR_TARGET的最大值是3600秒，当你设定的值超过3600秒，Oracle会按照3600秒来运行。
3. 请为FAST_START_MTTR_TARGET设置一个实际可行的值。原则上FAST_START_MTTR_TARGET的最小值是1秒（先不讨论0的情况），但是把数值设的很低并不意味着你可以达成这个目标，因为最低的MTTR TARGET是有限制的，它依赖于你数据库的启动时间等因素。你数据库实际能达到的MTTR TARGET称为effective MTTR target。你可以通过查询V$INSTANCE_RECOVERY视图的TARGET_MTTR列来查看该值。所以假如你将FAST_START_MTTR_TARGET设置过低不仅没有什么作用，反而还会因为频繁的checkpointing writes操作降低了数据库的性能。同样假如你将FAST_START_MTTR_TARGET设置过高，他也不会比在你数据库最遭情况下（整个缓存中都是脏数据）花的时间更长。（原文：If you set FAST_START_MTTR_TARGET to a time longer than the practical range, the MTTR target will be no better than the worst-case situation.）

2        如何调整FAST_START_MTTR_TARGET

在初步认识了FAST_START_MTTR_TARGET参数之后，将对他的用法进一步的学习。

首先，为了有效调节FAST_START_MTTR_TARGET参数，必须确保你的系统在标准工作量（typical workload）上运行了足够长的时间，同时，执行过一些实例恢复操作，从而保证了在恢复期间所记录的读取redo块和读写数据块的时间是准确的。

接着，开始决定FAST_START_MTTR_TARGET的实际可行范围。

第一步，确定FAST_START_MTTR_TARGET的下边界。将FAST_START_MTTR_TARGET设置为1，启动你的数据库。之后查询V$INSTANCE_RECOVERY视图中的TARGET_MTTR参数，此时的TARGET_MTTR就是FAST_START_MTTR_TARGET的最小值。

1	TARGET_MTTR ESTIMATED_MTTR

2

3	----------- --------------

4

5	38             22

可以发现，虽然FAST_START_MTTR_TARGET设置为1，但它的启动仍需38秒。由此可见，对于下边界的设置，数据库的启动时间比缓存恢复时间更能起到决定作用。

同时也有个疑问，为什么它的ESTIMATED_MTTR会比TARGET_MTTR——即最小值还小呢？这是因为ESTIMATED_MTTR是平均恢复时间的预期值，依赖于当前正在运行的数据库。而此时的数据库因为是刚刚启动，在它的缓存中只有非常少的脏数据，所以才会出现低于最小值的情况。ESTIMATED_MTTR的值会在短期内受到最近数据库活动的影响。只要做一个简单的测试就可以验证。比如对数据库进行频繁的更新操作。

1

declare

2

3	k number:=20000;

4

5

begin

6

7	while(k<50000)loop

8

9	update sta_finance set  sta_salary=k where sta_id=201000014;

10

11	k := k + 1;

12

13

end loop;

14

15

end;

此时再查询V$INSTANCE_RECOVERY视图会发现

1	TARGET_MTTR ESTIMATED_MTTR

2

3	----------- --------------

4

5	38             41

ESTIMATED_MTTR的值大于了TARGET_MTTR值。我们再等上一会儿，等待ckpt进程发出检查点，促使后台进程DBWn将脏数据写入数据文件。然后再次查询V$INSTANCE_RECOVERY视图，此时

查看源代码

打印 帮助

1	TARGET_MTTR ESTIMATED_MTTR

2

3	----------- --------------

4

5	38             39

ESTIMATED_MTTR数值降下来了，这是因为一些脏数据被写到数据文件中了。

第二步，确定FAST_START_MTTR_TARGET的上边界。为了确定FAST_START_MTTR_TARGET的上边界，需要先将FAST_START_MTTR_TARGET设置为它的最大值3600，然后操纵你的数据库在标准工作量下跑一会儿。此时再查看V$INSTANCE_RECOVERY视图，它的TARGET_MTTR所显示的值就是一个很好的上边界值。

通过一、二两步大体上可以确定FAST_START_MTTR_TARGET的实际范围。

接着第三步，确定一个初步可行的FAST_START_MTTR_TARGET值。这就看不同人对数据库的要求了。假如更关心数据库的性能，那么在范围内选择一个较大的值。假如希望更短的恢复时间，那么就选一个较小的数值。范围越小，选择就越容易。

最后，为了得到一个理想的值，就需要用到MTTR Advisor了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22531473/viewspace-743133/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22531473/viewspace-743133/