FAST_START_MTTR_TARGET enables you tospecify the number of seconds the database takes to perform crash recovery of asingle instance. When specified, FAST_START_MTTR_TARGET is overridden byLOG_CHECKPOINT_INTERVAL.
对于Fast-Start Fault Recovery特性,FAST_START_MTTR_TARGET参数能够简化配置实例或系统故障的恢复时间。FAST_START_MTTR_TARGET 指定了期望的平均恢复时间。平均恢复时间是指,启动实例并执行 cache recovery 所需时间(s)。
首先,为了有效调节FAST_START_MTTR_TARGET参数,必须确保你的系统在典型工作量上运行了足够长的时间,同时,执行过一些实例恢复操作,从而保证了在恢复期间所记录的读取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的最小值。
SQL> select TARGET_MTTR, ESTIMATED_MTTRfrom v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
38 22
可以发现,虽然FAST_START_MTTR_TARGET设置为1,但它的平均启动仍需38秒。这个下边界的值基于数据库的平均启动时间。
同时也有个疑问,为什么它的ESTIMATED_MTTR会比TARGET_MTTR——即最小值还小呢?这是因为ESTIMATED_MTTR是评估的平均恢复时间的预期值,依赖于当前正在运行的数据库。而此时的数据库因为是刚刚启动,在它的缓存中只有非常少的脏数据,所以才会出现低于最小值的情况。ESTIMATED_MTTR的值会在短期内受到最近数据库活动的影响。只要做一个简单的测试就可以验证。比如对数据库进行频繁的更新操作。此时再查询V$INSTANCE_RECOVERY视图会发现
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
38 41
ESTIMATED_MTTR的值大于了TARGET_MTTR值。我们再等上一会儿,等待ckpt进程发出检查点,促使后台进程DBWn将脏数据写入数据文件。然后再次查询V$INSTANCE_RECOVERY视图,此时
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
38 39
ESTIMATED_MTTR数值降下来了,这是因为一些脏数据被写到数据文件中了。
第二步,确定FAST_START_MTTR_TARGET的上边界。为了确定FAST_START_MTTR_TARGET的上边界,需要先将FAST_START_MTTR_TARGET设置为它的最大值3600,然后操纵你的数据库在典型工作量下跑一会儿。此时再查看V$INSTANCE_RECOVERY视图,它的TARGET_MTTR所显示的值就是一个很好的上边界值。
SQL> select TARGET_MTTR, ESTIMATED_MTTRfrom v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
85 22
通过一、二两步大体上可以确定FAST_START_MTTR_TARGET的实际范围。
接着第三步,确定一个初步可行的FAST_START_MTTR_TARGET值。这就看不同人对数据库的要求了。假如更关心数据库的性能,那么在范围内选择一个较大的值。假如希望更短的恢复时间,那么就选一个较小的数值。范围越小,选择就越容易。
接下来,你可以使用MTTR Advisor来决定一个比较优的FAST_START_MTTR_TARGET参数值。
开启MTTR Advisor
设置 STATISTICS_LEVEL 和 FAST_START_MTTR_TARGET参数。
设置STATISTICS_LEVEL为TYPICAL或ALL,并且设置FAST_START_MTTR_TARGET 为非0值。
开启MTTR Advisor之后,运行数据库在典型的工作负荷下一段时间,oracle会以当前的FAST_START_MTTR_TARGET参数值来模拟检查点队列行为,在可用的FAST_START_MTTR_TARGET参数值范围内增加4种不同的MTTR设置。
自动调整检查点
如果将FAST_START_MTTR_TARGET参数设置为0,将启用自动调整的检查点。
确认是否启用自动调整检查点:
SQL> show parameter fast_start_mttr_target; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ fast_start_mttr_target integer 0 SQL> SQL> select RECOVERY_ESTIMATED_IOS REIOS,TARGET_MTTR TMTTR, 2 ESTIMATED_MTTR EMTTR,WRITES_MTTR WMTTR,WRITES_OTHER_SETTINGS WOSET, 3 CKPT_BLOCK_WRITES CKPTBW,WRITES_AUTOTUNE WAUTO,WRITES_FULL_THREAD_CKPT WFTCKPT 4 from v$instance_recovery; REIOS TMTTR EMTTR WMTTR WOSET CKPTBW WAUTO WFTCKPT ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 74 0 9 0 0 3484 5633 0在以上视图中,WRITES_AUTOTUNE字段值就是指由于自动调整检查点执行的写出次数,而CKPT_BLOCK_WRITES指的则是由于检查点写出的Block的数量。
设置比较优的重做日志大小
你可以使用 V$INSTANCE_RECOVERY.OPTIMAL_LOGFILE_SIZE 来决定重做日志的大小。它基于当的设置,以M为单位。如果重做日志文件大小小于V$INSTANCE_RECOVERY.OPTIMAL_LOGFILE_SIZE的值,你应该配置所有重做日志文件最小为这个值。
Note, however, that the redo log file sizeaffects the MTTR. In some cases, you may be able to refine your choice of theoptimal FAST_START_MTTR_TARGET value by re-running the MTTR Advisor with yoursuggested optimal log file size.
两个重要的视图
V$INSTACNE_RECOVERY
V$MTTR_TARGET_ADVICE
Configuring the Duration of Cache Recovery: FAST_START_MTTR_TARGET
http://docs.oracle.com/cd/B19306_01/backup.102/b14191/rcmtunin.htm#i1015453