watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

          subject         part

stay Oracle in , Parameters FAST_START_MTTR_TARGET What is the role of ?


     
          Answer section          



Through parameters FAST_START_MTTR_TARGET You can specify the number of seconds the database will take to perform a single instance crash recovery ( By background process SMON Realization ), It can be considered as a parameter to speed up instance recovery . Based on internal statistics , Incremental checkpoints automatically adjust checkpoint targets , To satisfy FAST_START_MTTR_TARGET The requirements of . stay Oracle 8i in , Initialize parameters FAST_START_IO_TARGET Causes incremental checkpoints to automatically adjust their targets , So that the number of data blocks required for recovery is not more than FAST_START_IO_TARGET Set the value of the . since Oracle 9i Start , This parameter has been deprecated , Instead, the parameters FAST_START_MTTR_TARGET, And this parameter has become the preferred method to optimize the incremental checkpoint target .

from Oracle 10g Start ,FAST_START_MTTR_TARGET The default value is 0, That is to open the self-adjusting check point (self-tune checkpointing), The implicit parameter corresponding to the self-tuning checkpoint is “_DISABLE_SELFTUNE_CHECKPOINTING”, This value defaults to FALSE.

If set explicitly FAST_START_MTTR_TARGET by 0, There will be a prompt in the alarm log :

1MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
     

If this parameter is set to not 0, It means on MTTR Advisory(STATISTICS_LEVEL Parameter must be TYPICAL perhaps ALL), At this time, there will be no more information prompts in the alarm log . If the value is set too small , There will also be hints :

1FAST_START_MTTR_TARGET 45 is set too low, using minimum achievable MTTR 48 instead.
     

about MTTR The following views are important :

l V$INSTANCE_RECOVERY.ESTIMATED_MTTR Shows the current estimated average recovery time (MTTR,Mean Time To Recovery, In seconds ). Even if no FAST_START_MTTR_TARGET, It will also show this value .

l V$INSTANCE_RECOVERY.TARGET_MTTR Shows the validity enforced by the system MTTR The goal is ( In seconds ).

l V$MTTR_TARGET_ADVICE Show in the current MTTR Set the... Generated by the current workload I/O Number , And in others MTTR Set the forecast that will be generated by the current workload I/O Number . This view helps users with runtime performance and settings FAST_START_MTTR_TARGET To achieve a trade-off between rapid recovery . If not open MTTR Advisory Then the content of this view is empty .

In addition, we need to pay attention to LOG_CHECKPOINT_INTERVAL Parameters , This parameter specifies that the incremental checkpoint target should lag behind the maximum at the end of the current log Redo Number of pieces . If you specify FAST_START_MTTR_TARGET, Then you should not set LOG_CHECKPOINT_INTERVAL Or set it to 0. In most Unix On the system , The operating system block size is 512 byte . in other words , If you will LOG_CHECKPOINT_INTERVAL Is set to 10000 This means that the delta checkpoint target should not lag behind the current log tail by more than 5M. Based on this calculation , If Redo The size of the log is 20M, Then it will generate... For each log 4 A checkpoint .LOG_CHECKPOINT_INTERVAL It will affect the occurrence time of checkpoints , This means that special attention should be paid to the setting of this parameter , Keep it with Redo Log file size changes and updates . The frequency of checkpoints is one of the factors that affect the time it takes for a database to recover from an unexpected failure . The longer the interval between checkpoints , In the event of a system crash , The longer it takes to recover the database . The shorter the checkpoint interval means the faster the database recovers , But the cost is that checkpoint operations consume more resources . This parameter also affects the time required to complete the database recovery operation during the roll forward phase of the recovery . The actual recovery time depends on this time , And other factors , For example, fault type ( Instance or system crash 、 Medium failure, etc ) And the archives that need to be applied Redo Number of logs .