【OCP最新题库解析(052)–题23】Which two affect the time taken for ins
- 2019 年 10 月 10 日
- 笔记
Q
题目
Which two affect the time taken for instance recovery?
A. Size of archivelogs.
B. Size of existing RMAN backupsets.
C. FAST_START_MTTR_TARGET value.
D. Size of UNDO tablespace.
E. UNDO_RETENTION value.
F. Size of redo logs.
A
答案
Answer：CF
参考第2题。
FAST_START_MTTR_TARGET初始化参数可以简化实例或系统故障的恢复时间配置。MTTR指导可将FAST_START_MTTR_TARGET值转换为多个参数，以便在所需时间内（或者在尽量接近此时间的范围内）启用实例恢复。请注意，将FAST_START_MTTR_TARGET参数显式设置为0会禁用MTTR指导。
FAST_START_MTTR_TARGET参数的设置值必须支持系统的服务级协议。如果MTTR目标的值较小，则会因增加了数据文件写入次数而增加I/O开销（这会影响性能）。但是，如果MTTR目标设置得过大，则实例在崩溃后需要花费较长的时间才会恢复。
通过参数FAST_START_MTTR_TARGET可以指定数据库执行单实例的崩溃恢复所要花费的秒数（由后台进程SMON实现），可以认为是一个加快实例恢复的参数。基于内部统计信息，增量检查点会自动调整检查点目标，以满足FAST_START_MTTR_TARGET的要求。在Oracle 8i中，初始化参数FAST_START_IO_TARGET会使增量检查点自动调整其目标，从而使恢复所需的数据块数量不多于FAST_START_IO_TARGET设置的值。自Oracle 9i开始，已弃用此参数，取而代之的是参数FAST_START_MTTR_TARGET，并且该参数已成为优化增量检查点目标的首选方法。
从Oracle 10g开始，FAST_START_MTTR_TARGET默认值为0，即开启自调节检查点（self-tune checkpointing），自调节检查点对应隐含参数为“_DISABLE_SELFTUNE_CHECKPOINTING”，该值默认为FALSE。
若显式设置FAST_START_MTTR_TARGET为0，则在告警日志中会有提示：
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
若该参数设置为非0，则表示开启MTTR Advisory（STATISTICS_LEVEL参数必须为TYPICAL或者ALL），此时告警日志中不会再有以上信息提示了。若该值设置太小，则也会有提示：
FAST_START_MTTR_TARGET 45 is set too low, using minimum achievable MTTR 48 instead.
对于MTTR以下视图比较重要：
V$INSTANCE_RECOVERY.ESTIMATED_MTTR显示当前预计的平均恢复时间（MTTR，Mean Time To Recovery，以秒为单位）。即使未指定FAST_START_MTTR_TARGET，也同样会显示此值。
V$INSTANCE_RECOVERY.TARGET_MTTR显示由系统强制执行的有效MTTR目标（以秒为单位）。
V$MTTR_TARGET_ADVICE显示在当前的MTTR设置下由当前的工作负载产生的I/O数量，以及在其它MTTR设置下将由当前的工作负载产生的预计I/O数量。此视图可帮助用户在运行时性能和设置FAST_START_MTTR_TARGET以实现快速恢复之间进行权衡。若未开启MTTR Advisory则此视图内容为空。
参数LOG_CHECKPOINT_INTERVAL指定增量检查点目标应滞后于当前日志尾的最大Redo块数量。如果指定了FAST_START_MTTR_TARGET，那么就不应设置LOG_CHECKPOINT_INTERVAL或将其设置为0。在大多数Unix系统上，操作系统块大小都是512字节。也就是说，如果将LOG_CHECKPOINT_INTERVAL的值设置为10000，那么就意味着增量检查点目标相对于当前日志尾的滞后不得超过5M。以此计算，如果Redo日志的大小为20M，那么会对每个日志产生4个检查点。LOG_CHECKPOINT_INTERVAL会影响检查点的发生时间，这意味着应特别注意此参数的设置，保持其随Redo日志文件的大小变化而更新。检查点的频率是影响数据库从意外故障中恢复所需时间的因素之一。检查点之间的间隔越长，则在发生系统崩溃时，数据库恢复所需的时间就越长。检查点间隔越短意味着数据库的恢复速度越快，但是代价是检查点操作会消耗更多的资源。此参数还会影响在恢复的前滚阶段期间完成数据库恢复操作所需的时间。实际的恢复时间取决于此时间，以及其它因素，例如故障类型（实例或系统崩溃、介质故障等）以及需要应用的归档Redo日志数量。
