Oracle Fast-Start Fault Recovery 说明
官网的链接：
http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF13015
一.Instance Recovery
Instance andcrash recovery are the automatic application of redo log records to Oracle datablocks after a crash or system failure. During normal operation, if an instanceis shut down cleanly (as when using aSHUTDOWN IMMEDIATE statement), ratherthan terminated abnormally, then the in-memory changes that have not beenwritten to the data files on disk are written to disk as part of the checkpointperformed during shutdown.
--在db crash 或者 system failure 之后，启动DB时会根据redolog 做instance 和 crash recovery 操作。 当db shutdown cleanly时，会执行checkpint的操作，这样内存中已经改变的数据会写入到磁盘，这样在启动时，就是一致的。
However, if asingle instance database crashes or if all instances of an Oracle RAC configurationcrash, then Oracle Database performs crash recovery at the next startup. If oneor more instances of an Oracle RAC configuration crash, then a survivinginstance performs instance recovery automatically. Instance and crash recoveryoccur in two steps: cache recovery followed by transaction recovery.
The database canbe opened as soon as cache recovery completes, so improving the performance ofcache recovery is important for increasing availability.
1.1 Cache Recovery (Rolling Forward)
During the cacherecovery step, Oracle Database applies all committed and uncommitted changes inthe redo log files to the affected data blocks. The work required for cacherecovery processing is proportional to the rate of change to the database(update transactions each second) and the time between checkpoints.
--Cache Recovery 也叫前滚，会更具redo 的记录，重新应用所有已经commit的数据。
1.2 TransactionRecovery (Rolling Back)
To make thedatabase consistent, the changes that were not committed at the time of thecrash must be undone (in other words, rolled back). During the transactionrecovery step, Oracle Database applies the rollback segments to undo theuncommitted changes.
--Transaction Recovery 也叫回滚，其是为了保证数据，对于已经写入数据块的数据，且没有commited，回滚到uncommit 之前。
有关Crash 下的更多说明，参考：
Oracle 实例恢复时 前滚（roll forward） 后滚（rollback） 问题
http://blog.csdn.net/tianlesoftware/article/details/6286330
1.3 Checkpointsand Cache Recovery
Periodically,Oracle Database records a checkpoint. A checkpoint is the highestsystem change number (SCN) such that all data blocks less than or equal to thatSCN are known to be written out to the data files. If a failure occurs, thenonly the redo records containing changes at SCNs higher than the checkpointneed to be applied during recovery. The duration of cache recovery processingis determined by two factors: the number of data blocks that have changes atSCNs higher than the SCN of the checkpoint, and the number of log blocks thatneed to be read to find those changes.
--Oracle 会定时的执行checkpoint 操作，生成一个SCN号，SCN 一下的数据都是已经写入到disk。
必须先进行roll forward(从redo log file中从目前的start SCN开始，重做后面的已提交之交易)。 再从roll back segment 做rollback未完成(dead transaction)交易。
1.3.1 HowCheckpoints Affect Performance
Frequentcheckpointing writes dirty buffers to the data files more often than otherwise,and so reduces cache recovery time in the event of an instance failure. Ifcheckpointing is frequent, then applying the redo records in the redo logbetween the current checkpoint position and the end of the log involvesprocessing relatively few data blocks. This means that the cache recovery phaseof recovery is fairly short.
--增加checkpoint的频率，可以更及时的将dirty buffer 写入datafiles，这样在redo log里当前的checkpoint到redo log 的结束的内容就少。 所以发生crash，恢复的时间也相对较短。
However, in ahigh-update system, frequent checkpointing can reduce run-time performance, becausecheckpointing causes DBWn processes to perform writes.
--但是增加checkpoint，会降低数据库的性能，因为checkpoint 需要DBWn 进程执行写操作。
1.3.2 FastCache Recovery Tradeoffs
To minimize theduration of cache recovery, you must force Oracle Database to checkpoint often,thus keeping the number of redo log records to be applied during recovery to aminimum. However, in a high-update system, frequent checkpointing increases theoverhead for normal database operations.
--为了减少cache recover 的时间，就必须强制数据库执行checkpoint的频率，这样就可以保证recovery 时需要应用最少的redo log 记录。 但是高压力的系统下，频繁的执行checkpoint，也会增加DB的压力。
If dailyoperational efficiency is more important than minimizing recovery time, thendecrease the frequency of writes to data files due to checkpoints. This shouldimprove operational efficiency, but also increase cache recovery time.
二. Configuring the Duration of Cache Recovery: FAST_START_MTTR_TARGET
The Fast-Start Fault Recovery feature reduces the time required forcache recovery, and makes the recovery bounded and predictable by limiting thenumber of dirty buffers and the number of redo records generated between themost recent redo record and the last checkpoint.
--Fast-Start Fault Recovery 特性减少了cacherecovery 的时间，其对dirty buffer 和 自最后一次checkpoint 以来生成的redorecords 进行了限制。
The foundationof Fast-Start Fault Recovery is the Fast-Start checkpointing architecture.Instead of conventional event-driven (that is, log switching) checkpointing, whichdoes bulk writes, fast-start checkpointing occurs incrementally. EachDBWn process periodically writes buffers to disk to advance the checkpointposition. The oldest modified blocks are written first to ensure that everywrite lets the checkpoint advance. Fast-Start checkpointing eliminates bulkwrites and the resultant I/O spikes that occur with conventional checkpointing.
--Fast-Start Fault Recovery 的基础是Fast-Startcheckpointing 架构。 FSFR 取代传统的事件驱动checkpointing，其使用bulk write，增量的fast-start checkpointing。
每个DBWn 进程定时的将buffers的内容写入disk，来提高checkpoint的位置。
With theFast-Start Fault Recovery feature,the FAST_START_MTTR_TARGET initialization parameter simplifies theconfiguration of recovery time from instance or systemfailure. FAST_START_MTTR_TARGET specifies a target for the expectedmean time to recover (MTTR), that is, the time (in seconds) that it should taketo start up the instance and perform cache recovery.After FAST_START_MTTR_TARGET is set, the database manages incrementalcheckpoint writes in an attempt to meet that target. If you have chosen apractical value for FAST_START_MTTR_TARGET, you can expect your databaseto recover, on average, in approximately the number of seconds you have chosen.
在初始化参数里配置FAST_START_MTTR_TARGET参数启用Fast-Start Fault Recovery 特性， FAST_START_MTTR_TARGET参数的单位是秒，它控制实例启动和执行cache recovery。 设置FAST_START_MTTR_TARGET参数之后，DB 管理增量的checkpoint.可以给这个参数设置我们期望执行recover 的时间，一般来说，执行的recovery 的时间会这个时间接近。
注： 这里的MTTR= mean time to recover
Note:
You must disableor remove the FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL,and LOG_CHECKPOINT_TIMEOUT initialization parameters when using FAST_START_MTTR_TARGET.Setting these parameters interferes with the mechanisms used to manage cacherecovery time to meet FAST_START_MTTR_TARGET.
注意： 当我们设置FAST_START_MTTR_TARGET参数时，必须禁用或者移除 FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL,and LOG_CHECKPOINT_TIMEOUT 参数。
--默认值如下：
SQL> show parameter FAST_START_IO_TARGET
NAME TYPE VALUE
----------------------------------------------- ------------------
fast_start_io_target integer 0
SQL> show parameterlog_checkpoint_interval
NAME TYPE VALUE
----------------------------------------------- ------------------
log_checkpoint_interval integer 0
SQL> show parameterlog_checkpoint_timeout
NAME TYPE VALUE
----------------------------------------------- ------------------
log_checkpoint_timeout integer 1800
2.1 Practical Values for FAST_START_MTTR_TARGET
The maximumvalue for FAST_START_MTTR_TARGET is 3600 seconds (one hour). If youset the value to more than 3600, then Oracle Database rounds it to 3600.
--FAST_START_MTTR_TARGET 参数的最大值是3600秒，也就是一个小时，如果设置这个参数值大于3600秒，那么Oracle也会将该参数修改成3600.
官网对这个参数的单独说明，参考：
FAST_START_MTTR_TARGET
http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams087.htm#REFRN10058
The followingexample shows how to set the value of FAST_START_MTTR_TARGET:
-- 修改示例：
SQL> ALTER SYSTEM SETFAST_START_MTTR_TARGET=30;
System altered.
SQL> show parameterfast_start_mttr_target
NAME TYPE VALUE
----------------------------------------------- ------------
fast_start_mttr_target integer 30
In principle,the minimum value for FAST_START_MTTR_TARGET is one second. However,the fact that you can set FAST_START_MTTR_TARGET this low does notmean that this target can be achieved. There are practical limits to theminimum achievable MTTR target, due to such factors as database startup time.
--理论上，FAST_START_MTTR_TARGET参数最小为1秒，如果小于这个值就可以认为这个target 可以被归档。
--默认值如下：
SQL> show parameterfast_start_mttr_target
NAME TYPE VALUE
----------------------------------------------- ----------
fast_start_mttr_target integer 0
The MTTR target thatyour database can achieve given the current valueof FAST_START_MTTR_TARGET is called the effective MTTR target.You can view your current effective MTTR by viewing the TARGET_MTTR columnof the V$INSTANCE_RECOVERY view.
V$INSTANCE_RECOVERY monitorsthe mechanisms available to users to limit recovery I/O. Those mechanisms are:
(1) Setthe LOG_CHECKPOINT_TIMEOUT initialization parameter
(2) Setthe LOG_CHECKPOINT_INTERVAL initialization parameter
(3) Setthe FAST_START_MTTR_TARGET initialization parameter
(4) Set the size of the smallestredo log
http://docs.oracle.com/cd/E11882_01/server.112/e25513/dynviews_2004.htm#REFRN30106
TARGET_MTTR 列的解释如下：
Effective MTTR (meantime to recover) target value in seconds. The TARGET_MTTR value iscalculated based on the value of the FAST_START_MTTR_TARGET parameter(the TARGET_MTTR value is used internally), and is usually anapproximation of the parameter's value. However, ifthe FAST_START_MTTR_TARGET parameter value is very small (forexample, one second), or very large (for example, 3600 seconds), thecalculation will produce a target value dictated by system limitations. In suchcases, the TARGET_MTTR value will be the shortest calculated time, orthe longest calculated time that recovery is expected to take.
If FAST_START_MTTR_TARGET isnot specified, the value of this field is the current estimated MTTR.
-- TARGET_MTTR的值通常接近于 FAST_START_MTTR_TARGET。如果这个参数没有设置，其参数值等于当前估算的值。
The practicalrange of MTTR target values for your database is defined to be the rangebetween the lowest achievable effective MTTR target for your database and thelongest that startup and cache recovery will take in the worst-case scenario(that is, when the whole buffer cache is dirty). "Determinethe Practical Range for FAST_START_MTTR_TARGET" describes theprocedure for determining the range of achievable MTTR target values, one stepin the process of tuning your FAST_START_MTTR_TARGET value.
Note:
It is usuallynot useful to set your FAST_START_MTTR_TARGET to a value outside thepractical range. If your FAST_START_MTTR_TARGET value is shorter thanthe lower limit of the practical range, the effect is as if you set it to thelower limit of the practical range. In such a case, the effective MTTR targetwill be the best MTTR target the system can achieve, but checkpointing will beat a maximum, which can affect normal database performance. If youset 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.2 ReducingCheckpoint Frequency to Optimize Run-Time Performance
To reduce thecheckpoint frequency and optimize run-time performance, you can do thefollowing:
--为了减少checkpoint 频率寄最优的性能，可以按如下设置：
（1）Set the valueof FAST_START_MTTR_TARGET to 3600. This enables Fast-Startcheckpointing and the Fast-Start Fault Recovery feature, but minimizes itseffect on run-time performance while avoiding the need for performance tuningof FAST_START_MTTR_TARGET.
--设置FAST_START_MTTR_TARGET参数为最大值。
（2）Size youronline redo log files according to the amount of redo your system generates.Try to switch logs at most every twenty minutes. Having your log files toosmall can increase checkpoint activity and reduce performance. Also note thatall redo log files should be the same size.
--根据系统来设置online redo log的大小，使归档切换的时间在20分钟左右，如果redolog 过小，会增加checkpoint，也会影响性能，同时所有的redo log 应该设置成大小。
2.3 Monitoring Cache Recovery with V$INSTANCE_RECOVERY
The V$INSTANCE_RECOVERY view displays the current recoveryparameter settings. You can also use statistics from this view to determinewhich factor has the greatest influence on checkpointing.
-- V$INSTANCE_RECOVERY 视图显示当前recovery 参数的值。
The followingtable lists those columns most useful in monitoring predicted cache recoveryperformance:
Table 10-4 V$INSTANCE_RECOVERY Columns
Column | Description |
| Effective MTTR target in seconds. This field is 0 if |
| The current estimated MTTR in seconds, based on the current number of dirty buffers and log blocks. This field is always calculated, whether |
As part of theongoing monitoring of your database, you can periodicallycompare V$INSTANCE_RECOVERY.TARGET_MTTR toyour FAST_START_MTTR_TARGET. The two values should generally be the sameif theFAST_START_MTTR_TARGET value is in the practical range.If TARGET_MTTR is consistently longerthan FAST_START_MTTR_TARGET, then set FAST_START_MTTR_TARGET toa value no less than TARGET_MTTR. IfTARGET_MTTR is consistentlyshorter, then set FAST_START_MTTR_TARGET to a value no greaterthan TARGET_MTTR.
可以比较V$INSTANCE_RECOVERY.TARGET_MTTR和 FAST_START_MTTR_TARGET的值，如果相差较大，就调整他们到一致。
三. Tuning FAST_START_MTTR_TARGET and Using MTTR Advisor
To determine the appropriate valuefor FAST_START_MTTR_TARGET for your database, use the following fourstep process:
--可以使用如下方法来优化FAST_START_MTTR_TARGET的值：
(1) Calibratethe FAST_START_MTTR_TARGET
(2) Determinethe Practical Range for FAST_START_MTTR_TARGET
(3) EvaluateDifferent Target Values with MTTR Advisor
(4) DetermineOptimal Size for Redo Logs
3.1 Calibrate theFAST_START_MTTR_TARGET
The FAST_START_MTTR_TARGET initializationparameter causes the database to calculate internal system trigger values, inorder to limit the length of the redo log and the number of dirty data buffersin the data cache. This calculation uses estimated time to read a redo block,estimates of the time to read and write a data block and characteristics oftypical workload of the system, such as how many dirty buffers corresponds tohow many change vectors, and so on.
--db 根据FAST_START_MTTR_TARGET的值来计算内部系统的触发器的值，从而来限制redo log的记录数以及dirty buffer 的数量。 这个计算结果用来估算读取read block 的时间，及datablock 的读写时间。
Initially,internal defaults are used in the calculation. These defaults are replaced overtime by data gathered on I/O performance during system operation and actualcache recoveries.
--起初会使用一个内部的默认值来计算，随后会根据I/O 的性能，以及实际cache recovery的信息来代替这个默认值。
You will have toperform several instance recoveries in order to calibrateyour FAST_START_MTTR_TARGET value properly. Before startingcalibration, you must decide whether FAST_START_MTTR_TARGET is beingcalibrated for a database crash or a hardware crash. This is a consideration ifyour database files are stored in a file system or if your I/O subsystem has amemory cache, because there is a considerable difference in the read and writetime to disk depending on whether the files are cached. The appropriate valuefor FAST_START_MTTR_TARGET will depend upon which type of crash ismore important to recover from quickly.
--可以执行几次instance recovery来校准FAST_START_MTTR_TARGET的值。 在启动校准之前，需要确定是针对db crash 还是 hardware crash。根据不同的系统，在读写性能上有很大出入。
To effectivelycalibrate FAST_START_MTTR_TARGET, ensure that you run the typical workloadof the system for long enough, and perform several instance recoveries toensure that the time to read a redo block and the time to read or write a datablock during recovery are recorded accurately.
3.2 Determinethe Practical Range for FAST_START_MTTR_TARGET
Aftercalibration, you can perform tests to determine the practical range for FAST_START_MTTR_TARGET foryour database.
--校准之后可以执行一些测试，来确定参数的范围值。
3.2.1 Determining Lower Bound for FAST_START_MTTR_TARGET: Scenario –确定参数的下届值
To determine thelower bound of the practical range, set FAST_START_MTTR_TARGET to 1,and start up your database. Then check the value of V$INSTANCE_RECOVERY.TARGET_MTTR,and use this value as a good lower bound for FAST_START_MTTR_TARGET.Database startup time, rather than cache recovery time, is usually the dominantfactor in determining this limit.
--为了决定参数具体的lower bound，设置FAST_START_MTTR_TARGET参数为1，然后启动数据库，在检查TARGET_MTTR参数：
For example, set the FAST_START_MTTR_TARGET to1:
SQL> ALTER SYSTEM SETFAST_START_MTTR_TARGET=1;
Then, execute the following queryimmediately after opening the database:
SQL> SELECT TARGET_MTTR, ESTIMATED_MTTR
FROM V$INSTANCE_RECOVERY;
Oracle Database responds with thefollowing:
TARGET_MTTR ESTIMATED_MTTR
18 15
The TARGET_MTTR valueof 18 seconds is the minimum MTTR target that the system can achieve, that is,the lowest practical value for FAST_START_MTTR_TARGET. This minimum iscalculated based on the average database startup time.
--根据上面的查询结果，18秒是最小的MTTR target 值，因此，也就是FAST_START_MTTR_TARGET参数的最小值，其是根据db 的平均启动时间计算出来的。
The ESTIMATED_MTTR fieldcontains the estimated mean time to recovery based on the current state of therunning database. Because the database has just opened, the system contains fewdirty buffers, so not much cache recovery would be required if the instancefailed at this moment. That is why ESTIMATED_MTTR can, for themoment, be lower than the minimum possible TARGET_MTTR.
-- ESTIMATED_MTTR field 是估算的值，其是根据当前的运行状态估算出来的。 因为数据库刚启动，包含很少的dirty buffer，如果这个时候出现crash，cache recovery的工作会很少。
ESTIMATED_MTTR canbe affected in the short term by recent database activity. Assume that youquery V$INSTANCE_RECOVERY immediately after a period of heavy updateactivity in the database. Oracle Database responds with the following:
TARGET_MTTR ESTIMATED_MTTR
18 30
-- ESTIMATED_MTTR 参数会受DB最近的活动影响，如果我们执行了一个很大的update 操作，在查询ESTIMATED_MTTR的值，就会从15变成30.
Now theeffective MTTR target is still 18 seconds, and the estimated MTTR (if a crashhappened at that moment) is 30 seconds. This is an acceptable result. Thismeans that some checkpoints writes might not have finished yet, so the buffercache contains more dirty buffers than targeted.
--但是MTTR target 还是18秒,这个是正常的现象，出现这种情况，也就意味着checkpoints 写操作可能还没有结束，所以buffer cache 包含的dirty buffers 超过target。
Now wait forsixty seconds and reissue the query to V$INSTANCE_RECOVERY. OracleDatabase responds with the following:
TARGET_MTTR ESTIMATED_MTTR
18 25
The estimatedMTTR at this time has dropped to 25 seconds, because some of the dirty buffershave been written out during this period
--在过一分钟来查询，就可以发现ESTIMATED_MTTR的值变成了25. 因为一些dirtybuffers 已经写到disk了。
3.2.2 DeterminingUpper Bound for FAST_START_MTTR_TARGET
To determine theupper bound of the practical range, set FAST_START_MTTR_TARGET to3600, and operate your database under a typical workload for a while. Thencheck the value ofV$INSTANCE_RECOVERY.TARGET_MTTR. This value is a good upperbound for FAST_START_MTTR_TARGET.
--测试FAST_START_MTTR_TARGET的upperbound，可以将参数值设置为最大的3600，然后查询V$INSTANCE_RECOVERY.TARGET_MTTR.具体操作和测试lowerbound 类似。
3.2.3 Selecting Preliminary Value for FAST_START_MTTR_TARGET
After you havedetermined the practical bounds for the FAST_START_MTTR_TARGET parameter,select a preliminary value for the parameter. Choose a higher value within thepractical range if your concern is with database performance, and a lower valuewithin the practical range if your priority is shorter recovery times. Thenarrower the practical range, of course, the easier the choice becomes.
--在上面2小节里，我们可以测试出FAST_START_MTTR_TARGET 的上限和下限值。 那么我们需要在这个范围内选出一个初始值。其值越大，DB 性能越好，其值越小，recovery 的时间越短。
For example, ifyou discovered that the practical range was between 17 and 19 seconds, it wouldbe quite simple to choose 19, because it makes relatively little difference inrecovery time and at the same time minimizes the effect of checkpointing onsystem performance. However, if you found that the practical range was between18 and 40 seconds, you might choose a compromise value of 30, and set theparameter accordingly:
SQL> ALTERSYSTEM SET FAST_START_MTTR_TARGET=30;
You might then go on to use the MTTRAdvisor to determine an optimal value.
--如果我们检测的参数范围是17到19，那么我们选择19，因为值越大，性能越好。如果是18到40. 我们可能就会选择30. 但是最好使用MTTR Advisor 来决定最优的值。
3.3 Evaluate Different Target Values with MTTR Advisor
After you haveselected a preliminary value for FAST_START_MTTR_TARGET, you can use MTTRAdvisor to evaluate the effect of different FAST_START_MTTR_TARGET settingson system performance, compared to your chosen setting.
3.3.1 Enabling MTTR Advisor –启用MTTRAdvisor
To enable MTTRAdvisor, set the two initialization parameters STATISTICS_LEVEL and FAST_START_MTTR_TARGET.
STATISTICS_LEVEL governs whether alladvisors are enabled and is not specific to MTTR Advisor. Ensure that it is setto TYPICAL or ALL. Then, when FAST_START_MTTR_TARGET isset to a nonzero value, the MTTR Advisor is enabled.
--确保STATISTICS_LEVEL 值为TYPICAL 或者ALL。 然后将 FAST_START_MTTR_TARGET设置为非0值。
3.3.2 Using MTTR Advisor
After enablingMTTR Advisor, run a typical database workload for a while. When MTTR Advisor isON, the database simulates checkpoint queue behavior under the current value of FAST_START_MTTR_TARGET,and up to four other different MTTR settings within the range of valid FAST_START_MTTR_TARGET values.(The database will in this case determine the valid range for FAST_START_MTTR_TARGET itselfbefore testing different values in the range.)
--启用MTTR Advisor 之后，执行一个完整的事务操作。 在MTTRAdvisor 打开的情况下，db 会在当前 FAST_START_MTTR_TARGET值下模仿checkpoints队列的行为。 会生成4个不同的MTTR 设置。 所以在测试之前需要先确定参数的范围，在这里设置其最大值。
3.3.3 ViewingMTTR Advisor Results: V$MTTR_TARGET_ADVICE
The dynamicperformance view V$MTTR_TARGET_ADVICE lets you view statistics oradvisories collected by MTTR Advisor.
--从V$MTTR_TARGET_ADVICE的动态性能视图查看收集的MTTR Advisor 信息。
The databasepopulates V$MTTR_TARGET_ADVICE with advice about the effects of eachof the FAST_START_MTTR_TARGET settings for your database. For eachpossible value of FAST_START_MTTR_TARGET, the row contains details abouthow many cache writes would be performed under the workload tested for thatvalue of FAST_START_MTTR_TARGET.
Specifically,each row contains information about cache writes, total physical writes(including direct writes), and total I/O (including reads) for that value of FAST_START_MTTR_TARGET,expressed both as a total number of operations and a ratio compared to theoperations under your chosen FAST_START_MTTR_TARGET value. Forinstance, a ratio of 1.2 indicates 20% more cache writes.
Knowing theeffect of different FAST_START_MTTR_TARGET settings on cache writeactivity and other I/O enables you to decide better which FAST_START_MTTR_TARGET valuebest fits your recovery and performance needs.
If MTTR Advisoris currently on, then V$MTTR_TARGET_ADVICE shows the Advisorinformation collected. If MTTR Advisor is currently OFF, then the viewshows information collected the last time MTTR Advisor wasON sincedatabase startup, if any. If the database has been restarted since the lasttime the MTTR Advisor was used, or if it has never been used, the view will notshow any rows.
--如果MTTR Advisor 是ON的，那么V$MTTR_TARGET_ADVICE 会显示当前的收集的信息，如果是OFF的，则会显示上次的信息。如果从来没有使用过，则为空。
3.4 Determine Optimal Size for Redo Logs
You can use the V$INSTANCE_RECOVERY viewcolumn OPTIMAL_LOGFILE_SIZE to determine the size of your online redologs. This field shows the redo log file size in megabytes that is consideredoptimal based on the current setting of FAST_START_MTTR_TARGET. If thisfield consistently shows a value greater than the size of your smallest onlinelog, then you should configure all your online logs to be at least this size.
-- V$INSTANCE_RECOVERY 视图的OPTIMAL_LOGFILE_SIZE列会根据FAST_START_MTTR_TARGET参数计算出来的最优的redo 大小，其单位是MB。
我们的online redo 至少要大于这个值。
Note, however,that the redo log file size affects the MTTR. In some cases, you may be able torefine your choice of the optimal FAST_START_MTTR_TARGET value byre-running the MTTR Advisor with your suggested optimal log file size.
--当然，redo log 的大小也是受MTTR 的影响，所以先设定好最优的FAST_START_MTTR_TARGET，然后在调整redo log 大小。
四. AWR 报告中有关Instance Recovery 说明
从这个AWR报告中，我们也可以看出MTTR的信息，我这里没有设置Target MTTR，所以这里显示为0.Estd MTTR 是估算的值。
-------------------------------------------------------------------------------------------------------
版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!
Blog: http://blog.csdn.net/tianlesoftware
Weibo: http://weibo.com/tianlesoftware
Email: tianlesoftware@gmail.com
Skype: tianlesoftware
-------加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请----
DBA1 群：62697716(满); DBA2 群：62697977(满) DBA3 群：62697850(满)
DBA 超级群：63306533(满); DBA4 群：83829929 DBA5群： 142216823
DBA6 群：158654907 DBA7 群：172855474
