参数FAST_START_MTTR_TARGET的理解

一、FAST_START_MTTR_TARGET参数的作用和实现方法

 

参数FAST_START_MTTR_TARGET参数是一个加快实例恢复的参数,我们可以根据服务界别来定义一个合理的、可接受的值。该值得单位为秒。比如设定为60S,假定该值处于合理的情况之下,则一旦实例崩溃,在60S以内实例应当能够被恢复。合理即该值不能太大,也不能太小。太大则实例恢复所需的时间较长,太小则导致大量数据的及时写入,增加了系统的I/O。

影响实例恢复时间长短的主要因素是从最近检查点位置到联机重做日志尾部之间的距离。距离越长则所需要的cache recovery和undo、redo的时间越长。所以如何有效的缩短最近检查点位置与联机重做日志尾部之间的距离,正是FAST_START_MTTR_TARGET的目的。

FAST_START_MTTR_TARGET的值实际上是通过触发检查点来实现它的目的的。当内存中产生的dirty buffer所需的恢复时间(estimated_mttr)到达FAST_START_MTTR_TARGET所指定的时间,则检查点进程被触发。检查点进程一旦被触发,将通过DBWn进程按检查点队列顺序将脏数据写入到数据文件,从而缩短了最后检查点位置与联机重做日志间的距离,减少了实例恢复所需的时间。

 

二、FAST_START_MTTR_TARGET参数为0的情况

 

官网描述:

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.

 

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设置为0将关闭检查点自动调整功能。当设定一个大于0的值给FAST_START_MTTR_TARGET,则自动调整检查点功能将启用。

 

三、设置FAST_START_MTTR_TARGET

 

这个参数值得设定需要考虑到可接受的实例的恢复时间、可承受的I/O吞吐量等等。可以再系统正常负载时参考v$instance_recovery视图来设置该参数的值。

 

假定将FAST_TARGET_MTTR_TARGET的值设置为30S:

SYS@ tsid > alter system set
fast_start_mttr_target=30;

 

视图v$instance_recovery中有两个相关字段:TARGET_MTTR和ESTIMATED_MTTR

TARGET_MTTR:参照FAST_START_MTTR_TARGET参数中设定的值计算出来的一个值。

ESTIMATED_MTTR:系统根据dirty
buffer中计算出来的值。

 

SYS@tsid>select recovery_estimated_ios,actual_redo_blks,target_redo_blks,target_mttr,estimated_mttr

  2  from
v$instance_recovery;

 

RECOVERY_ESTIMATED_IOS
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR

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

                  1768           104036           184320          28             23

 

 

四、启用MTTR
Advisor

 

首先需要设置两个参数:STATISTICS_LEVEL,设置为typical或者all

                       FAST_START_MTTR_TARGET,设置为非0值。

 

SYS@ tsid > show parameter
mttr;  --当前参数设置为30S

 

NAME                                 TYPE        VALUE

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

fast_start_mttr_target               integer     30

 

   

SYS@
tsid > select target_mttr,estimated_mttr from v$instance_recovery;

 

TARGET_MTTR ESTIMATED_MTTR

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

         28             23                     --系统计算出的mttr为28S

 

SYS@tsid>select
mttr_target_for_estimate,dirty_limit,estd_cache_writes,estd_cache_write_factor,estd_total_writes,estd_total_write_factor
from v$mttr_target_advice;

 

MTTR_TARGET_FOR_ESTIMATE
DIRTY_LIMIT ESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTOR ESTD_TOTAL_WRITES
ESTD_TOTAL_WRITE_FACTOR

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

                      27        1000             75103                  1.0043             75296              1.0043

                      28        1103             74974                  1.0026             75167              1.0026

                      30        1313             74781                       1             74974                   1

                      31        1417             74652                   .9983             74845               .9983

                      32        1522             74587                   .9974             74780               .9974

 

--mttr_target_for_estimate有一个值最接近设定的目标时间30。

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

时间: 2025-01-27 16:14:43

参数FAST_START_MTTR_TARGET的理解的相关文章

java中final 变量作为方法的参数?怎么理解?见下面代码

问题描述 java中final 变量作为方法的参数?怎么理解?见下面代码 class NiMingLei { public static void main(String[] args) { Outer out= new Outer(); out.function(7); out.function(8); } } class Outer { static int y=4; void function(final int a) { class Inter { void method() { Sys

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

--=============================================== --对参数FAST_START_MTTR_TARGET = 0 的误解及设定 --===============================================           笔者Google了一下关于描述了FAST_START_MTTR_TARGET参数,看到很多文章将该参数置为0时为启用自动调整的检查点功能     如:Oracle10gR2自动检查点调整的新特性    

对imp中的fromuser参数的偏差理解

这两天执行导入dump文件时总碰到一个问题. 问题现象: 1. 执行:imp xyz/xxx file=test.dmp log=imp_test.log fromuser=test1 touser=test2 ignore=y commit=y buffer=300000000 feedback=10000 注:这个文件dump>200G容量. 2. 执行了许久,但最后结果和log中记录: Connected to: Oracle Database 10g Enterprise Edition

[20170515]参数fast_start_mttr_target

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

基于php-fpm 参数的深入理解_php实例

ps aux |grep php-fpm |more查看php-fpm总数php-fpm.conf 配置pid stringPID文件的位置. 默认为空.error_log string错误日志的位置. 默认: 安装路径#INSTALL_PREFIX#/log/php-fpm.log.log_level string错误级别. 可用级别为: alert(必须立即处理), error(错误情况), warning(警告情况), notice(一般重要信息), debug(调试信息). 默认: no

再次理解C语言的变参

实在是令我很郁闷的事啊. 去年用了两天的时间恶补了一下变参,今天看到变参.发现头脑一篇空白,啥都不知道了.   古人有云:温故而知新.今日我就在看一遍,做个笔记了.   在 C 语言中,函数参数的 传递方式有值传和址传 . 值传是把实参的一个专用的.临时的复制值给被调函数中相应的形参 被调用函数使用.修改这个传来的复制值,不会影响实参的值 . 址传则 是把变量 ( 实参 ) 的地址传给被调函数 . 被调函数通过这个地址找到该变量的存放位置,直接对该地址中存放 的变量的内容进行存取操作 . 无论是

Yarn 内存分配管理机制及相关参数配置

理解Yarn的内存管理与分配机制,对于我们搭建.部署集群,开发维护应用都是尤为重要的,对于这方面我做了一些调研供大家参考. 关于Yarn的详细介绍请参考[Hadoop Yarn详解] 一.相关配置情况 关于Yarn内存分配与管理,主要涉及到了ResourceManage.ApplicationMatser.NodeManager这几个概念,相关的优化也要紧紧围绕着这几方面来开展.这里还有一个Container的概念,现在可以先把它理解为运行map/reduce task的容器,后面有详细介绍.

【分享】Java反序列化漏洞从理解到实践

一.前言 在学习新事物时,我们需要不断提醒自己一点:纸上得来终觉浅,绝知此事要躬行.这也是为什么我们在学到知识后要付诸实践的原因所在.在本文中,我们会深入分析大家非常熟悉的 Java发序列化漏洞 .对我们而言,最好的实践就是真正理解手头掌握的知识,并可以根据实际需要加以改进利用.本文的主要内容包括以下两方面: 1.    利用某个反序列化漏洞. 2.    自己手动创建利用载荷. 更具体一点,首先我们会利用现有工具来实际操作反序列化漏洞,也会解释操作的具体含义,其次我们会深入分析载荷相关内容,比

Java反序列化漏洞从理解到实践

一.前言 在学习新事物时,我们需要不断提醒自己一点:纸上得来终觉浅,绝知此事要躬行.这也是为什么我们在学到知识后要付诸实践的原因所在.在本文中,我们会深入分析大家非常熟悉的Java发序列化漏洞.对我们而言,最好的实践就是真正理解手头掌握的知识,并可以根据实际需要加以改进利用.本文的主要内容包括以下两方面: 1. 利用某个反序列化漏洞. 2. 自己手动创建利用载荷. 更具体一点,首先我们会利用现有工具来实际操作反序列化漏洞,也会解释操作的具体含义,其次我们会深入分析载荷相关内容,比如什么是载荷.如