对参数FAST_START_MTTR_TARGET = 0 的误解及设定

--===============================================

--对参数FAST_START_MTTR_TARGET = 0 的误解及设定

--===============================================

 

        笔者Google了一下关于描述了FAST_START_MTTR_TARGET参数,看到很多文章将该参数置为0时为启用自动调整的检查点功能

    如:Oracle10gR2自动检查点调整的新特性  

        对其中FAST_START_MTTR_TARGET=0为启用自动调整的检查点的这个观点笔者着是不敢苟同。

   

一、关于FAST_START_MTTR_TARGET参数

 

        是一个加快实例恢复的参数,我们可以根据服务级别来定义一个合理的、可接受的值,该值的单位为秒。比如设定为60s,即1分钟。

    假定该值处于合理的情况之下,则一旦实例崩溃,在60s以内实例应当能够被恢复。合理即是该值不能太大,也不能太小。太大则实例恢

    复所需的时间较长,太小则导致大量数据的及时写入,增加了系统的I/O。

   

        影响实例恢复时间长短的主要因素即是从最近检查点位置到联机重做日志尾部之间的距离。距离越长则所需要的cache recovery 和undo、

    redo的时间越长。所以如何有效的缩短最近检查点位置与联机重做日志尾部之间的距离,这正是FAST_START_MTTR_TARGET的目的。

   

        关于检查点的触发条件有很多,比如日志切换、数据库shutdown、开始结束备份表空间等。检查点的分类也很多,比如完全检查点、部

    分检查点、增量检查点等。

   

        FAST_START_MTTR_TARGET的值实际上也是触发检查点的一个触发条件。当内存中产生的dirty buffer所需的恢复时间(estimated_mttr)

    如果到达FAST_START_MTTR_TARGET的指定时间,则检查点进程被触发。检查点进程一旦被触发,将通知DBWn进程将按检查点队列顺序将脏数

    据写入到数据文件,从而缩短了最后检查点位置与联机重做日志间的距离,减少了实例恢复所需的时间。

   

        关于实例的恢复以及检查的具体分类描述等,请参考:

            Oracle 实例恢复

            Oracle实例和Oracle数据库(Oracle体系结构)           

 

二、FAST_START_MTTR_TARGET = 0的质疑

   

        很多文章描述了FAST_START_MTTR_TARGET = 0,即为未设置,表示启用自动检查点功能,下面是来自Oracle的官方文档中的一段,

    原文的链接为:Fast-Start Fault Recovery

   

        Fast-start checkpointing refers to the periodic writes by the database writer (DBWn) processes for the purpose of writing changed data blocks from the Oracle buffer cache to disk and advancing the thread-checkpoint. Setting the database parameter FAST_START_MTTR_TARGET to a value greater than zero enables the fast-start checkpointing feature. Fast-start checkpointing should always be enabled for the following reasons:

 

        It reduces the time required for cache recovery, and makes instance recovery time-bounded and predictable. This is accomplished by limiting the number of dirty buffers (data blocks which have changes in memory that still need to be written to disk) and the number of redo records (changes in the database) generated between the most recent redo record and the last checkpoint.

   

        Fast-Start checkpointing eliminates bulk writes and corresponding I/O spikes that occur traditionally with interval- based checkpoints, providing a smoother, more consistent I/O pattern that is more predictable and easier to manage. If the system is not  already near or at its maximum I/O capacity, fast-start checkpointing will have a negligible impact on performance. Although  fast-start checkpointing results in increased write activity, there is little reduction in database throughout, provided the system  has sufficient I/O capacity.

 

        从第一段中粗体标记的描述来看,当设定一个大于0的值给FAST_START_MTTR_TARGET,则自动调整检查点功能别启用。即fast-start

    checkpointing,更准确的说应该是快速启动检查点功能

   

        再看下面的这段描述,这段来自Oracle 10g OCP workshop I 14-17 英文版教程(Edition 3.1 December 2008)

   

        Explicit setting of the FAST_START_MTTR_TARGET parameter to 0 disables automatic checkpoint tuning.Explicit setting of the FAST_START_MTTR_TARGET parameter to a value other than 0 also enables the Redo Log Advisor.

   

        从上面的描述可以看出,如果将FAST_START_MTTR_TARGET设置为将关闭检查点自动调整功能。

       

三、设定FAST_START_MTTR_TARGET

        根据实际需要来设定FAST_START_MTTR_TARGET的值,这个值的设定需要考虑到可接受的实例的恢复时间、可承受的I/O吞吐量等等。

        假定我们将该值设定为

            SQL> alter system set fast_start_mttr_target = 30 ;

        在事务频繁的时间段来考察视图v$instacne_recovery提供的值

       

        SQL> desc v$instance_recovery;   --查看v$instance_recovery视图的结构

         Name                                      Null?    Type

         ----------------------------------------- -------- ----------------------------

         RECOVERY_ESTIMATED_IOS                             NUMBER

         ACTUAL_REDO_BLKS                                   NUMBER

         TARGET_REDO_BLKS                                   NUMBER

         LOG_FILE_SIZE_REDO_BLKS                            NUMBER

         LOG_CHKPT_TIMEOUT_REDO_BLKS                        NUMBER

         LOG_CHKPT_INTERVAL_REDO_BLKS                       NUMBER

         FAST_START_IO_TARGET_REDO_BLKS                     NUMBER

         TARGET_MTTR                                        NUMBER

         ESTIMATED_MTTR                                     NUMBER

         CKPT_BLOCK_WRITES                                  NUMBER

         OPTIMAL_LOGFILE_SIZE                               NUMBER

         ESTD_CLUSTER_AVAILABLE_TIME                        NUMBER

         WRITES_MTTR                                        NUMBER

         WRITES_LOGFILE_SIZE                                NUMBER

         WRITES_LOG_CHECKPOINT_SETTINGS                     NUMBER

         WRITES_OTHER_SETTINGS                              NUMBER

         WRITES_AUTOTUNE                                    NUMBER

         WRITES_FULL_THREAD_CKPT                            NUMBER

 

        两个字段:

            TARGET_MTTR         -->参照fast_start_mttr_target参数中设定的值计算出来的一个值

            ESTIMATED_MTTR      -->系统根据dirty buffer 中计算出来的值

        可能出现的情况

            1.TARGET_MTTR > ESTIMATED_MTTR  --大量的事务将导致这种情况的出现

            2.TARGET_MTTR < ESTIMATED_MTTR  --数据库刚刚启动时,几乎没有事务时会出现这种情况

 

SQL> select recovery_estimated_ios,actual_redo_blks ,target_redo_blks ,

  2  target_mttr,estimated_mttr

  3  from v$instance_recovery;

 

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR

---------------------- ---------------- ---------------- ----------- --------------

                    55              147              707          33             27

 

        可以在负载的情况下根据TARGET_MTTR来值通过v$mttr_target_advice调整该参数

 

四、启用MTTR Advisory

        需要设置两个参数

            STATISTICS_LEVEL         -->置为typical 或者all

            FAST_START_MTTR_TARGET   -->置为非零值

 

        SQL> show parameter mttr;    --目标mttr_time设定为30 s

 

        NAME                                 TYPE        VALUE

        ------------------------------------ ----------- ------------------------------

 

        fast_start_mttr_target               integer     30

 

        SQL> select  target_mttr,estimated_mttr from v$instance_recovery;   --系统计算出来的mttr为33

 

        TARGET_MTTR ESTIMATED_MTTR

        ----------- --------------

                 33             27     

 

        SQL> select mttr_target_for_estimate tar_est,dirty_limit,estd_cache_writes est_c_w,

          2  estd_cache_write_factor est_c_w_f,estd_total_writes est_t_w,estd_total_write_factor est_t_w_f

          3  from v$mttr_target_advice;

 

           TAR_EST DIRTY_LIMIT    EST_C_W  EST_C_W_F    EST_T_W  EST_T_W_F

        ---------- ----------- ---------- ---------- ---------- ----------

                60        5028       3762      .7376       3762      .7376

                34        1000       5100          1       5100          1

                68        6248       3762      .7376       3762      .7376

                52        3808       3762      .7376       3762      .7376

                45        2735       3845      .7539       3845      .7539

   

        --mttr_target_for_estimate有一个值为的最接近设定的目标时间30,以及由系统计算出的的target_mttr时间33

        --同时也给出了几组不同的mttr_target值及dirty_limit,cache_write,io 等来供DBA来选择设定合适的mttr

 

五、两个重要的视图

        v$instacne_recovery

        v$mttr_target_advice

   

六、更多   

Oracle实例和Oracle数据库(Oracle体系结构)

 

Oracle 用户、对象权限、系统权限

 

Oracle 角色、配置文件

 

  Oracle 联机重做日志文件(ONLINE LOG FILE)

 

  Oracle 控制文件(CONTROLFILE)

 

  Oracle 表空间与数据文件

 

时间: 2024-12-22 22:06:17

对参数FAST_START_MTTR_TARGET = 0 的误解及设定的相关文章

参数FAST_START_MTTR_TARGET的理解

一.FAST_START_MTTR_TARGET参数的作用和实现方法   参数FAST_START_MTTR_TARGET参数是一个加快实例恢复的参数,我们可以根据服务界别来定义一个合理的.可接受的值.该值得单位为秒.比如设定为60S,假定该值处于合理的情况之下,则一旦实例崩溃,在60S以内实例应当能够被恢复.合理即该值不能太大,也不能太小.太大则实例恢复所需的时间较长,太小则导致大量数据的及时写入,增加了系统的I/O. 影响实例恢复时间长短的主要因素是从最近检查点位置到联机重做日志尾部之间的距

c++中GetBuffer()的参数的0和1和2好像都没有区别?

问题描述 c++中GetBuffer()的参数的0和1和2好像都没有区别? 我把里面的参数设置成0,1,2,3,4,甚至是100,但好像都没有区别!我实在不晓得怎么理解这个函数了!~~~随便填真的不会出错吗? 解决方案 (1)LPTSTR GetBuffer( ); (2)LPTSTR GetBuffer(int nMinBufferLength) 在第二个版本中,当设定的长度小于原字符串长度时,nMinBufLength = nOldLen, 该参数会被忽略,不分配内存,指向原CString:

[20170515]参数fast_start_mttr_target

[20170515]fast_start_mttr_target容易混淆的地方.txt --//自己很少关注这个参数.但是确实非常容易混淆. 1.环境: SYS@book> @ &r/ver1 PORT_STRING         VERSION    BANNER ------------------- ---------- -------------------------------------------------------------------------------- x

多线程问题,中的sleep函数参数为0 的作用是什么 ?多线程问题,中的sleep函数

问题描述 多线程问题,中的sleep函数参数为0 的作用是什么 ?多线程问题,中的sleep函数 多线程问题,中的sleep函数参数为0 的作用是什么 ?多线程问题,中的sleep函数 解决方案 http://blog.csdn.net/lgstudyvc/article/details/9337063 解决方案二: 参数为零的调用的含义是当前线程自愿放弃CPU的竞争,便于操作系统进行新的CPU分配. 解决方案三: 参数为0表示主动调度一下,通常是一个线程需要等另外一个线程完成某个人物之后,自己

SureHA 1.0集群进入设定模式出现JAVA安全提示的解决方法

SureHA 1.0集群进入设定模式时,可能出现JAVA安全提示如下:   解决方案: 在运行输入:    代码如下 复制代码 notepad %HOMEDRIVE%%HOMEPATH%.java.policy 在弹出的记事本中输入(http后面的内容根据实际的提示填写)并保存.    代码如下 复制代码 grant codeBase "http://localhost:29003/clptrek.jar" {    permission java.security.AllPermis

使用strtotime和mktime时参数为0时返回1999-11-30的时间戳

   代码如下   <?php  $time = date('Y-m-d',strtotime('00-00-00 00:00:00'));  echo $time;  //输出 1999-11-30  ?> 这里没有任何bug,00-00-00的意思是2000-00-00,2000-00-00实际上是1999-12-00,而1999-12-00又会转换成1999-11-30. 所以这里没有任何bug,完全正常. strtotime('00-00-00 00:00:00')与 mktime(0

使用strtotime和mktime时参数为0时返回1999-11-30的时间戳问题

先看例子  代码如下 复制代码 <?php $time = date('Y-m-d',strtotime('00-00-00 00:00:00')); echo $time; //输出 1999-11-30 ?> 这里没有任何bug,00-00-00的意思是2000-00-00,2000-00-00实际上是1999-12-00,而1999-12-00又会转换成1999-11-30. 所以这里没有任何bug,完全正常. strtotime('00-00-00 00:00:00')与 mktime

收缩表段(shrink space)

--====================-- 收缩表段(shrink space)--==================== 一.表的增长方式    当表被创建后,随着记录的不断插入,组成表的区间会被填满,如果启用了自动扩展,则当区间填满后,会分配新的区间.假定高水    位线随着记录的增加从最左端往右端来移动,当到底部区间的尾端时,则新的区间将会被分配.    二.表可收缩的原理    随着记录的增加高水位线不断的右移,记录的删除不会导致高水位线往回(左)移动    删除记录后的空闲空间

db_block_checking与db_block_checksum

--************************************ -- db_block_checking 与 db_block_checksum --************************************     db_block_checking与db_block_checksum两个参数都是对block进行检查,然而两者很容易混淆.事实上,两个参数中前者是对块做逻 辑性检查,后者则是做物理性检查.两者各司其职,并不矛盾.下面分别给出具体描述. 1.db_blo