[20170515]参数fast_start_mttr_target

[20170515]fast_start_mttr_target容易混淆的地方.txt

--//自己很少关注这个参数.但是确实非常容易混淆.

1.环境:
SYS@book> @ &r/ver1
PORT_STRING         VERSION    BANNER
------------------- ---------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

--//如果不设置,也是缺省设置.
$ strings spfilebook.ora | grep -i fast_start_mttr_target

SYS@book> show spparameter fast_start_mttr_targ
SID      NAME                          TYPE    VALUE
-------- ----------------------------- ------- -------
*        fast_start_mttr_target        integer

SYS@book> show parameter fast_start_mttr_targ
NAME                   TYPE    VALUE
---------------------- ------- ------
fast_start_mttr_target integer 0

--//alert*.log:
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

SYS@book> select WRITES_AUTOTUNE from v$instance_recovery ;
WRITES_AUTOTUNE
---------------
             52
--//实际上这个时候是开启自动调整.
--//如果你设置0,自动关闭这个功能.

2.设置fast_start_mttr_target=0;

SYS@book> alter system set fast_start_mttr_target=0;
System altered.

SYS@book> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.

SYS@book> startup
ORACLE instance started.
Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.
Database opened.

--//alert*.log:

Mon May 15 10:40:15 2017
ARC0 started with pid=22, OS id=34420
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 opened at log sequence 745
  Current log# 3 seq# 745 mem# 0: /mnt/ramdisk/book/redo03.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
--//提示一样,但是现在是关闭的.

SYS@book> show parameter fast_start_mttr_targ
NAME                   TYPE    VALUE
---------------------- ------- -----
fast_start_mttr_target integer 0

SYS@book> show spparameter fast_start_mttr_targ
SID      NAME                   TYPE    VALUE
-------- ---------------------- ------- ------
*        fast_start_mttr_target integer 0

--//你等很久观察,这是WRITES_AUTOTUNE一直是0.
SYS@book> select WRITES_AUTOTUNE from v$instance_recovery ;
WRITES_AUTOTUNE
---------------
              0

3.设置fast_start_mttr_target=200:
SYS@book> alter system set fast_start_mttr_target=200;
System altered.

--//重启:
SYS@book> show parameter fast_start_mttr_targ
NAME                   TYPE    VALUE
---------------------- ------- ------
fast_start_mttr_target integer 200

SYS@book> show spparameter fast_start_mttr_targ
SID      NAME                   TYPE    VALUE
-------- ---------------------- ------- -----
*        fast_start_mttr_target integer 200

--//alert没有mttr的相关显示,表示已经MTTR advisory is enabled.

时间: 2025-01-27 06:27:35

[20170515]参数fast_start_mttr_target的相关文章

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

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

参数FAST_START_MTTR_TARGET的理解

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

参数CONTROL_FILE_RECORD_KEEP_TIME和MAXLOGHISOTRY

--************************************************** -- 参数 CONTROL_FILE_RECORD_KEEP_TIME 和MAXLOGHISOTRY --**************************************************       参数 control_file_record_keep_time 是一 个 位于控制文件中比 较 重要的 参数 之一. 它决 定了控制文件里可重 复 使用的 记录 所能保存的

调优日志切换(Tuning Log Switches)

调优日志切换(Tuning Log Switches)   日志切换:LGWR进程停止写日志到当前日志文件,关闭日志文件,打开新的日志文件并写日志缓存中的数据到新的日志文件.   日志切换可以命令ALTER SYSTEM SWITCH LOGFILE或者ALTER SYSTEM ARCHIVE LOG来手工执行,也可以通过设置参数LOG_ARCHIVE_START使其自动执行.一般的原因是一个进程不能将生成的重做日志从缓存中写到当前的日志文件,因为已经使用到当前日志文件的最后一个数据块.    

某人的oracle9i学习笔记,与大家分享

oracle|笔记 ######### 创建数据库----look $ORACLE_HOME/rdbms/admin/buildall.sql ############# create database db01 maxlogfiles 10 maxdatafiles 1024 maxinstances 2 logfile GROUP 1 ('/u01/oradata/db01/log_01_db01.rdo') SIZE 15M, GROUP 2 ('/u01/oradata/db01/log

收缩表段(shrink space)

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

实例恢复的原理+PGA +

原文整理自网络: 5.4.2.5  实例恢复的原理 前面我们讲到过,当数据库突然崩溃,而还没有来得及将buffer cache里的脏数据块刷新到数据文件里,同时在实例崩溃时正在运行着的事务被突然中断,则事务为中间状态,也就是既没有提交也没有回滚.这时数据文件里的内容不能体现实例崩溃时的状态.这样关闭的数据库是不一致的. 下次启动实例时,Oracle会由SMON进程自动进行实例恢复.实例启动时,SMON进程会去检查控制文件中所记录的.每个在线的.可读写的数据文件的END SCN号.数据库正常运行过

db_block_checking与db_block_checksum

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

Oracle 常用性能视图一览表(10g)

--*************************************-- Oracle 常用性能视图一览表(10g)--************************************* Advisors     Information related to cache advisors v$pga_target_advice v$shared_pool_advice v$pga_target_advice_histogram v$java_pool_advice v$mttr