登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

飞哥的技术博客

世上无难事,只怕有心人!

 
 
 

日志

 
 
 
 

fast_start_mttr_target,Oracle系列教程,Oracle技术教程,Oracle  

2009-07-07 22:50:23|  分类: Oracle |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
fast_start_mttr_target
 基于时间点的恢复限制
  我们提到了恢复时间取决于读取log files的时间和处理需要恢复的数据块
的时间。
  其中参数log_checkpoint_interval设定了恢复过程中将要被读的重做记录的数目。 fast_start_io_target控制了需要被恢复的数据块数目。然而,DBA可以通过单独设置参数来设置基于秒级的恢复时间限制。 LOG_CHECKPOINT_TIMEOUT限制了上一检查点和最近的重做记录之间的秒数。但他对于设置恢复时间限制来说都是不够精确的!
  新参数fast_start_mttr_target允许DBA指定数据库进行崩溃恢复需要的秒数。
实际上这个参数被转化为设置参数FAST_START_IO_TARGET,LOG_CHECKPOINT_INTERVAL两个参数。这个特性大大简化了限定数据库恢复时间,并增加了准确性。ast_start_mttr_target是一个动态参数,可以在线修改。例如:
alter system set fast_start_mttr_target =60;
在一个单实例数据库配置中fast_start_mttr_target的值是一个估测的崩溃平均恢复时间。在rac里。最坏的情况下,实例崩溃恢复时间是所有的在open
(read/write open)状态的实例的fast_start_mttr_target参数值的和。但是实际的恢复时间会少一些因为初始化和文件打开只需要做一次。
  然而,有一种情况下,在rac环境中,恢复时间会更少。因为一个失败的单实例
会被其他的已经打开的实例恢复到正常状态。需要失败恢复去覆盖rac中所有实例
的情况是一种比较极端的,很少发生的事情。  参数fast_start_mttr_target的范围是0-3600的一个整数。0是默认的,这表示恢复时间不是由这个参数来控制的。推荐大小取决于sga的大小。数据库的启动,取决于很多变化的因素,包括维护级别协定。我们发现恢复时间随着维护级别的偏重于不影响性能的变化,恢复时间线性增长。
  性能下降可以通过察看检查点后额外增加的块数目检测到。这些块作为一个严格限制恢复时间的结果。检查点统计被存放在statspack的输出中,也可以在v$instance_recovery视图中查到(列为ckpt_block_writes).
  在实例恢复时,oracle9i实例o重演以检查点重做字节地址为起始的变化。
   推进检查点位置能够控制恢复时间?检查点的推进由四个参数控制。
       – DB_BLOCK_MAX_DIRTY_TARGET
       – FAST_START_IO_TARGET
       – LOG_CHECKPOINT_INTERVAL
       – LOG_CHECKPOINT_TIMEOUT
  DB_BLOCK_MAX_DIRTY_TARGET:指定了buffer cache中dirty 
buffer的最大数目。
  FAST_START_IO_TARGET:指定了需要恢复的数据块数目,9i之前,这个参数控制了将要被读和写的数据块的数目,在双通道恢复中,这个参数等于需要被恢复的数据块数目。
  LOG_CHECKPOINT_INTERVAL:指定检查点和redo log结尾中间最大的重做记录数目。
  LOG_CHECKPOINT_TIMEOUT:指定了检查点处的重做记录多少秒开始写入。
注意:就算没有任何参数限定,检查点推进也会被最小日志得90%大小所控制。即:oracle强制这一行为是通过确认检查点
和最近重做记录之间的重做块的数目小于最小的日志的90%,如果参数log_checkpoint_interval的值小于最小日志的90%,那么最小日志的大小将不再影响检查点行为。
-------------------------------------------------------------------------------------
      参数变化
  db_block_max_dirty_target参数已经被去掉。
  如果fast_start_io_target or log_checkpoint_interval被
指定,他们会自动覆盖由fast_start_mttr_target参数计算出来
的值。
   log_checkpoint_timeout没有改变。
   新参数fast_start_mttr_target被内在的解释成两个参数:
fast_start_io_target和log_checkpoint_interval.如果这两个参数没有显式的指定,计算值将生效.
   如果fast_start_io_target或者log_checkpoint_interval被显式指定,这个内部计算的值将被忽略,指定的值将替代计算值.
    利用规则计算一些任务比如:初始化,文件打开,读日志,从数据文件中读取数据块,写数据块到数据文件中,这是一个适应性的规则,首先用内部计算来评估这些操作,然后当系统监测到可利用的现实数据后,会对这个数据进行替代.因此这个评估是比较精确的,因为服务器对自己的环境和独特的i/og 更了解.因为人工计算完成这些操作所需要的时间,并通过这些来计算控制恢复时间的参数是一项复杂的任务,因此这个特性大大简化了任务,并增加了实例恢复时间的准确性.
FAST_START_MTTR_TARGET中的mttr就是mean time to recovery,定义数据库进行crash恢复的时间,单位为秒。

    它不直接影响checkpoint事件,而是当内存中脏数据需要恢复时间estimated_mttr达到fast_start_mttr_target时,才触发checkpoint。

    如何定义FAST_START_MTTR_TARGET参数值可查看V$mttr_target_advice试图的建议。

   V$mttr_target_advice包含如下字段:

mttr_target_for_estimate,advice_status,dirty_limit,estd_cache_writes

estd_cache_write_factor,estd_total_writes,estd_total_write_factor

estd_total_ios

     MTTR 顾问工具能够统计 MTTR 造成的额外的物理写入操作,从而协助用户评估不同 MTTR 设置对系统性能的影响。MTTR 顾问工具启用,且系统在正常负载下运行一段时间后,用户可以查询 V$MTTR_TARGET_ADVICE 视图,获得其他 MTTR 设置与当前 MTTR 设置下数据库缓存写入操作的比率。例如,比率值为 1.2 表示某一 MTTR 设置将比当前设置增加 20% 的数据库缓存写入操作。




引文来源  fast_start_mttr_target,Oracle系列教程,Oracle技术教程,Oracle
  评论这张
 
阅读(417)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018