网站建设与管理专业工资高吗,网站域名 如何选择,招聘网站怎么做市场,深圳建设网站和公众号检 查 点 概述 ■l当修改数据时#xff0c;需要首先将数据读入内存中#xff08;Buffer Cache#xff09;#xff0c;修改数据的同时#xff0c;Oracle会记录重做信息#xff08;Redo#xff09;用于恢复。因 为有了重做信息的存在#xff0c;Oracle不需要在提交时… 检 查 点 概述 ■l当修改数据时需要首先将数据读入内存中Buffer Cache修改数据的同时Oracle会记录重做信息Redo用于恢复。因 为有了重做信息的存在Oracle不需要在提交时立即将变化的数据写回磁盘立即写的效率会很低重做Redo的存在也 正是为了在数据库崩溃之 后数据就可以恢复。 ■l最常见的情况数据库可以因为断电而Crash那么内存中修改过的、尚未写入文件的数据将会丢失。在下一次数据库启动之 后Oracle可以通过重做日志Redo进行事务重演也就是进行前滚将数据库恢复到崩溃之前的状态然后数据库可以打 开提供使用之后Oracle可以将 未提交的数据进行回滚。 ■在这个过程中通常大家最关心的是数据库要经历多久才能打开。也就是需要读取多少重做日志才能完成前滚。当然用户希望这 个时间越短越好Oracle也正是通过各种手段在不断优化这个过程缩短恢复时间。 检查点的存在就是为了缩短这个恢复时间。 checkpoint是数据库的一个内部事件它存在的根本意义在于减少崩溃恢复Crash Recovery时间。 发展 ■在Oracle8之前Oracle的检查点通常被称为常规检查点Conventional Checkpoint,这类检查点按一定的条件触发log_checkpoint_interval、log_checkpoint_timeout参数设置及log switch等条件出发。 ■从Oracle 8开始Oracle引入了增量检查点Inctrmental Checkpoint的概念。 和以前的版本相比在新版本中Oracle主要引入了检查点队列Checkpoinnt Queue机制增量检查点的主要宗旨就是定期 的刷新一部分脏块。将脏块一次刷新完是不合理的因为脏块不断产生没有穷尽。像完全检查点那样停止用户所有的修改操 作将脏块刷新完再继续这绝对会极大的影响性能。 ■所有增量检查点的一次刷新部分块是脏块问题的最好解决办法。 ■增量检查点就是根据块变脏的顺序每次刷新那些最早脏的块这种方式最为合理。 原理当检查点发生时此时的SCN被称为CheckPoint SCNOracle会通知DBWR进程将数据缓冲区里的脏数据块也就是Checkpoint SCN之前的脏数据Dirty Data从Buffer Cache写入磁盘当写入完成之后CKPT进程更新控制文件和数据文件头记录检查点信息标识变更。作用 保证数据库的一致性这是指将脏数据写出到硬盘保证内存和硬盘上的数据是一样的缩短实例恢复的时间 ■实例恢复要把实例异常关闭前没有写到硬盘的脏数据通过日志进行恢复。 ■如果脏块过多实例恢复的时间也会过长检查点的发生可以减少脏块的数量从而减少实例 恢复的时间。 ■通过LRBALOW REDO BUFFER ADRESSHRBAHIGH REDO BUFFER ADRESS HRBA是没有任何意义的但是LRBA非常有意义了CKPT会将最早脏块在redo记录里面位置 即LRBA写到控制文件里面去下次实例恢复读取控制文件就知道从redo记录的哪个位置开始恢复数据块 检查点 相关 rba■rba就是重做块地址,比如说,用户发出了一条update命令,更新了块A,块A现在变成了脏块,oracle会为他 生成一条重做记录.这条重做记录在重做日志文件中的位置就是rba(redo block address).过了一会儿,假 如:块A依然还是脏块,此时.用户又发出一条更新块A的命令,这又会生成一条重做记录.第一条更新命令对 应的重做记录的rba被称为块A的lrba(low rba),第二条更新命令对应的rba,被称为hrba(high rba).检查点队列 ■被修改过的块在oracle中都被统称为脏块.所有的脏块被一个链表串起来,称做检查点队列.在buffercache中,每一个块都有一个buffer header 简称BH,在BH中有一个ckptq项。 ■buffer header记录对应块在Buffer cache中的地址脏块对应 的重做记录在日志文件中的位置另外还有前一个节点、后一个节点的地址。 ■ckptq项此项目中记录了指向检查点队列上一个块和下一个块的指针.如果某一个块不在检查点队列中,他的ckptq项为空.通过ckptq项oracle将所有的脏块串成了一个双向链表.这个双向链表就是检查点队列。 ■只有脏块才会在检查点队列中,非脏块的ckptq为空。 ■ 每个块在它变脏时会被链接到检查点队列的末尾。就好像排队一样9:00来的人站在第一位9:05来的人排第二位以后每来一个人都站在 队伍的末尾这个队伍就是按来到的时间顺序排列的一个队列。检查点队列就是这样块在变脏时会被按照Low RBA的顺序第一次对比数据 块修改对应的Redo Byte Address链到末尾。 ■ 当块首次被更改时,块会立即被加进检查点队列.如果检查点队列中的脏块再次被修改,并不会改变其在 检查点队列中的位置。因此检查点队列是按块变脏的时间顺序将块排成了一个队列。 ■检查点队列就是这样块在变脏时会被按照Low RBA的顺序第一次对比数据 块修改对应的Redo Byte Address链到末尾。其实,按照lrba来排列,就是按照块首次被修改的顺序来排列. 检查点位置 ■检查点队列的头又被称为检查点位置Checkpoint postion。总之检查点位置就是检查点队列头。检查点队列头节点也就是检查点位置的信息Oracle会频繁的将它记录到控制文件中而且会很频繁的记录。一般是每隔三秒有一个专门的进程CKPT会将检查点位置记录进控制文件。 ■检查点位置对应的日志地址RBA又总是被记录在控制文件中。如果发生系统崩溃这个最后的检查点位置就是实例恢复运用日志的起点 DBWR写脏块 Oracle会定期唤醒DBWn从检查点队列头开始沿着检查点队列的顺序刷新脏块数据缓冲区里的脏数据块CKPT进程使用非常轻量级的控制文件更新协议将当前的最低RBA写入控制文件。在刷新脏块的同时仍可以不断的有新的脏块被链接到检查点队列的尾部。 定期唤醒DBWn刷新脏块的操作Oracle就称为增量检查点。因为增量检查点可以连续地进行因此检查点RBA可以比常规检查点更接近数据库的最后状态从而在数据库的实例恢复中可以极大地减少恢复时间。 分类 完全 检查 点 完全检查点发生时,将不能有新的脏块产生,直到完全检查点完成 1.记下当前的scn, 将此scn之前所有的脏块一次性写完 2.将该scn号同步更新控制文件和数据文件头。 3.把新的连机重做日志的第一重做记录的RBA写进数据文件头 可以引起完全检查点的四个动作 a)正常关闭数据库:shutdown immediate b)手动检查点切换:alter system checkpoint; c)日志切换alter system switch logfile; d)数据库热备模式alter database begin backup; ■当发生日志切换时,也会触发检查点.在数据库并不繁忙的情况下日志切换的检查点并不急于完成.之所以在日志切换的时候触发一次检查点,是为了保证重做日志文件所对应的脏块都被写进磁盘文件。 ■如果写脏块的速度比较慢,日志文件循环一圈后,又该覆盖此日志文件时,而此日志文件的检查点还没有完成,那么覆盖操作将等待.等待事件名:log file switch(checkpoint incomplete).如果出现该等待事件,解决方法: 1,可以增加日志文件组的数量。 2,观察下增量检查点的间隔时间.如果是因为增量检查点间隔时间太长,导致积攒的脏块过多。 可以把增量检查点参数设置的频繁点. 日志切换检查点除了会触发DBWR写脏块外CKPT进程还要将切换时的SCN写进数据文件头和控制文件中的数据库信息节,还有数据文件节.另外还要将新的连机重做日志文件中第一条重做记录的RBA写进数据文件头. 增量 检查点 1增量检查点使检查点位置前移。进而缩短实例恢复需要的日志起点和终点之间的距离触发增量检查点越频繁实例恢复的时间越短但数据库性能受到频繁IO影响会降低。 2增量检查点并不会去更新数据文件头以及控制文件中数据库SCN以及数据文件条目的SCN信息而只是每3秒由CKPT进程去更新控制文件中的lowcache rba信息 也就是检查点的位置。 3如果发生了实例崩溃只需要在日志文件中找到检查点位置(low cache rba),从此处开始应用所有的重做日志文件就完成了前滚操作。实例崩溃后再次启动数据库oracle会到控制文件中读取low cache rba 这就是检查点位置。从此处开始应用重做日志应用到on disk rba的位置。on diskrba是磁盘中重做日志文件的最后一条重做记录的rba. 查 看 select CPDRT,CPLRBA_SEQ||.||CPLRBA_BNO||.||CPLRBA_BOF LowRBA,CPODR_SEQ||.||CPODR_BNO||.||
CPODR_BOF 0n disk RBA,CPODS,CPODT,CPHBT from x$kcccp;CPDRT Low RBA On disk RBA CPODS CPODT CPHBT
---------- --------------- --------------- ---------------- -------------------- ----------35 686.124.0 686.220.0 2325376 03/02/2008 15:18:54 648319278CPDRT列是检查点队列中的脏块数目.
CPODS列是on disk rba的scn
on disk rba是磁盘中重做日志文件的最后一条重做记录的rba. 如果某条命令的重做记录的rba高于on disk rba那说明此重做记录还没有被写进日志文件中崩溃发生时他是不可能被恢复的.
on disk rba是oracle前滚操作的终点.
on disk 顾名思义 就是在磁盘上的意思.比这个更高的rba,都在log buffer中,还没有来的急被写进磁盘中的日志文件.所以是不能被用于恢复的.
CPODT列是on disk rba的时间戳
CPHBT列是心跳 参 数 在10g中把 log_checkpoint_to_alert设置为真,可以在告警日志中观察到增量检查点的触发.在9I中看不到增量检查点,可以看到其他检查点的触发信息。 SQL alter system set log_checkpoints_to_alerttrue;
系统已更改。
步骤2:将增量检查点的切换频率定为300秒.log_checkpoint_timeout
该参数用于表示检查点位置和重做日志尾之间的时间间隔,以秒为单位,
默认情况下是1800秒,
这个参数实际上表示了脏块保持脏状态的最长时间。
如果它被定为1800秒,没有脏块保持1800秒后,还是为脏
LOG_CHECKPOINT_INSTERVAL
该参数是表示检查点位置和重做日志末尾的块的数量.以OS表示.LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL参数
根据这个参数Oracle计算出在内存中累积的dirty buffer所需
的日志恢复时间如果到达该参数指定的时间则增量检查点进程
被触发。该参数如果为0ORACLE则会根据Oracle将根据产生脏
块的速度、存贮硬件的性能自动调节检查点的频率让DBWN进程自
身尽量减少写入量这样虽然实现了性能最大化但实例恢复时间
可能会比较长
SQL alter system set log_checkpoint_timeout300;[单位是秒]
系统已更改。局部检查点 触发命令 SQLalter system checkpoint local; 这条命令显示的触发一个局部检查点。 对于某些操作局部检查点是必须的并会自动执行。 比如表空间offline,数据文件offline,删除extent,表truncate,begin backup(将表空间置于备份模式等。Oracle会根据需要自动执行 处理步骤 获取实例状态队列实例状态队列是在实例状态转变时获得ORACLE获得此队列以保证CHECKPIONT执行期间数据库处于打开状态获取当前CHECKPIONT信息获取CHECKPIONT记录信息的结构此结构包括当前CHECKPIONT时间、活动线程、进行CHECKPIONT处理的当前线程、日志文件中恢复截止点的地址信息缓存区标识标识所有脏缓存区当CHECKPIONT找到一个脏缓存区就将其标识为需要进行刷新标识的脏缓存区由系统进程DBWR进行写操作将脏缓存区的内容写入数据文件脏缓存区刷新DBWR进程将所有脏缓存区写入磁盘后设置一标志标识已完成脏缓存区至磁盘的写入操作。系统进程LGWR与CKPT进程将继续进行检查直至DBWR进程结束为止更新控制文件与数据文件控制文件与数据文件头包含CHECKPIONT结构信息用户修改块 1如果块不在Buffer cache将块读入Buffer cache 2先生成重做记录并记入日志缓存在用户提交时写到日志文件中 3在Buffer cache中修改块 4在Buffer cache中设置块的脏标志位标志块变成脏块同时在检查点队列末尾增加一个新节点记录这个新脏块的信息信息包括脏块在Buffer cache中的位置在步骤2时生成的与此脏块对应的重做记录位置。 5用户提交后将相应的重做记录从重做缓存写入日志文件 C K P T 数据库中有个CKPT进程这个是个可选进程但是真正执行检查点的任务并不是有ckpt来完成的而是ckpt在更新控制文件和数据文件头的有关信息后通知DBWn进程产生一个检查点在产生检查点的时候DBWn进程会将buffer cache中的脏数据(当前online redo log对应的脏数据)写入我们的数据文件当中。那么这个时候如果数据库此时崩溃比如我们做个shutdown abort那么在进行实例恢复的时候就可以不需要当前online redo log的内容了会很快就做完。 任务■监控着检查点队列的长度,当检查点队列的长度达到一定限制时,CKPT会通知DBWR写脏块.CKPT会根据参数的设置和I/O的速度以及繁忙程度,计算出来一个Target rba(目标rba),DBWR会沿着检查点队列,将所有Target rba之前的脏块刷新到磁盘.当CKPT通知完DBWR Target rba后,CKPT的任务就结束了每3秒,检测一次DBWR的写进度.检查点队列最前面的块被称为检查点位置.DBWR是沿着检查点队列写脏块的,CKPT每3秒钟查看一下DBWR沿检查点队列写到了哪里,并且将这个位置设置为检查点位置.也就是说检查点位置之前的块,都是已被DBWR刷新到磁盘上的块.这个3秒一次检查DBWR进度的工作,也是CKPT的一个重要的任务 CKPT每3秒一次将检查点位置记录进控制文件,当然同时被记录进控制文件的还有心跳等其他信息. CKPT每3秒一次的工作和CKPT定期触发DBWR这两项操作合一起被称为--增量检查点. 因此ckpt进程只是个辅助进程他的任务更多的是用来在系统做checkpoint的时候更新控制文件和数据文件头中的信息。其实在oracle 8i的时候呢ckpt的任务一般都是由lgwr进程来完成到了8i以后随着CKPT进程的引入lgwr的工作负担就减轻了很多(commit的速度加快了) 检查点 不做更新 在两种情况下文件头中的检查点信息获取当前检查点信息时将不做更新 1数据文件不处于热备份方式此时ORACLE将不知道操作系统将何时读文件头而备份拷贝在拷贝开始时必须具有检查点SCNORACLE在数据文件头中保留一个检查点的记数器在正常操作中保证使用数据文件的当前版本在恢复时防止恢复数据文件的错误版本即使在热备份方式下计数器依然是递增的每个数据文件的检查点计数器也保留在控制文件相对应数据文件项中。 2检查SCN小于文件头中的检查点SCN的时候这表明由检查点产生的改动已经写到磁盘上在执行全局检查点的处理过程中如果一个热备份快速检查点在更新文件头时则可能发生此种情况。应该注意的是ORACLE是在实际进行检查点处理的大量工作之前捕获检查SCN的并且很有可能被一条象热备份命令 alter tablespace USERS begin backup进行快速检查点处理时的命令打断。 ORACLE在进行数据文件更新之前将验证其数据一致性当验证完成即更新数据文件头以反映当前检查点的情况未经验证的数据文件与写入时出现错误的数据文件都被忽略如果日志文件被覆盖则这个文件可能需要进行介质恢复在这种情况下ORACLE系统进程DBWR将此数据文件脱机 如果FAST_START_MTTR_TARGET0v$log视图中的active状态几分钟后会变成inactive状态然后更新了控制文件和日志文件头部的SCN与提交区别 事务在没有提交或者回滚之前对于其他的用户会话是看不到的即数据修改了但是对于其他人是不可见的因为没有提交。提交了的数据还是可能在内存未提交的数据也可能在磁盘。在未提交之前发出alter system checkpoint那么所有修改了的数据块都写到磁盘上面了虽然未提交但是数据还是写到磁盘上面了因为未提交其他会话依旧看不到数据修改的变化。 对于一个事务的提交与否和在磁盘内存没有任何关系。对于commit来说是来保证数据的永久的改变这些改变在磁盘还是在内存改变都不重要总之就是改变了。 Checkpoint就是将内存凡是修改过的数据块就写到磁盘上面修改的数据块有两种情况一种是修改完提交一种是修改完未提交。所以checkpoint只管将修改了的数据块写到磁盘上面。 事务发出一个commit之后这个时候Oracle就认为将这个数据块永久的改变了。commit表示事务的结束事务的结束就意味着别人对操数据的结果可见。哪怕修改了100W条记录没有commit对于其他的用户依然查看不到修改了的数据。commit标识事务的结束标识修改数据的生效生效是在内存生效还是磁盘生效都不重要。 总结commit就是让事务提交让事务生效让修改过后的数据对于其他用户可见。如果生效的数据在磁盘上面别的用户查的时候就去磁盘上读取出来如果生效的数据在内存里面那么在内存里面就是可以看到的。 commit之后不是将修改过后的脏数据块写到磁盘上面redo log开始是放在内存里面的commit之后会强迫log buffer里面的redo log无条件的必须写到磁盘上面。只有磁盘写成功了commit才会返回给客户端提交完成的信息。在Oracle里面数据是由redo来保护的为什么不将修改了的数据直接写到磁盘上面为什么还要让redo去写。因为写redo速度快redo是顺序写的是从一个文件从头写到尾。而要将数据块写到磁盘上面先要去磁盘上面找数据块的位置然后再写入这样非常耗时。一旦redo信息写到磁盘上面就没有问题了即使数据块丢失了也可以通过redo找回来。 redo一写到磁盘上这个数据就安全了既然安全了为什么还要checkpoint呢 第一就是给别人让位置脏数据会越来越多的最后内存会放不下所以脏数据最后还是得刷到磁盘上面给其他新产生的脏数据让出位置。 第二在恢复的时候减少时间redo是可以将数据保护起来如果有大量的数据都在内存里面比如说有好几个G的数据在内存里面没有刷到磁盘上面数据库坏了恢复的时候因为大量数据的丢失到导致恢复的时候需要很长时间。所以checkpoint就是将一些数据及时的写到磁盘上面一旦写到磁盘上面就不需要恢复了。 那么是否要通过checkpoint经常来将脏数据写到磁盘上面呢效率的问题因为频繁的写到磁盘上面是随机写I/O效率低。 算法 脏缓存区用一个新队列链接称为检查点队列。对缓存区的每一个改动都有一个与其相关的重做值。检查点队列包含脏的日志缓存区这些缓存区按照它们在日志文件中的位置排序即在检查点队列中缓存区按照它们的低重做值进行排序。需要注意的是由于缓存区是依照第一次变脏的次序链接到队列中的所以如果在缓存区写出之前对它有另外的改动链接不能进行相应变更缓存区一旦被链接到检查点队列它就停留在此位置直到将它被写出为止。 ORACLE系统进程DBWR在响应检查点请求时按照这个队列的低重做值的升序写出缓存区。每个检查点请求指定一个重做值一旦DBWR写出的缓存区重做值等于或大于检查点的重做值检查点处理即完成并将记录到控制文件与数据文件。 由于检查点队列上的缓存区按照低重做值进行排序而DBWR也按照低重做值顺序写出检查点缓存区故可能有多个检查点请求处于活动状态当DBWR写出缓存区时检查位于检查点队列前端的缓存区重做值与检查点重做值的一致性如果重做值小于检查点队列前缓存区的低重做值的所有检查点请求即可表示处理完成。当存在未完成的活动检查点请求时DBWR继续写出检查点缓存区。 算法特点 1DBWR能确切的知道为满足检查点请求需要写那些缓存区 2在每次进行检查点写时保证指向完成最早的具有最低重做值的检查点 3根据检查点重做值可以区别多个检查点请求然后按照它们的顺序完成处理 参数与命令 在数据库中增量检查点是通过Fast-Start Checkpointing特性来实现的从Oracle 8i开始这一特性包含了Oracle企业版的Fast-Start Fault Recovery组件之中 select * from V$option where ParameterFast-Start Fault Recovery; 该组件包含3个主要特性可以加快系统在故障后的恢复提高系统的可用性。 Fast-Start Checkpointing 特性在Oracle 8i中主要通过参数FAST_START_IO_TARGET来实现 Fast-Start CheckpointingFast-Start On-Demand RollbackFast-Start Parallel Rollback fast_start_io_target 该参数用于表示数据库发生Instance Recovery 的时候需要产生的IO总数,他通过v$filestat的AVGIOTIM来估算的.比如我们一个数据库发生Instance Crash后需要在10分钟内恢复完毕,假定OS的IO每秒为500个,那么这个数据库发生Instance Recovery的时候大概产生500*10*6030,000次IO,也就是我们将可以把fast_start_io_target设置为30000 在9i之前DBA主要靠fast_start_io_target间隔时间等方式来设置增量检查点的频率比如可以让Oracle每10分钟发生一次增量检查点。如果这个数字设置不合适对数据库性能的影响是很大的。而且有可能造成实例恢复时间过长 在Oracle 9i中Fast-Start Checkpointing主要通过参数FAST_START_MTTR_TARGET来实现。 mttr是mean time to recovery的简写该参数定义数据库进行Crash恢复的时间单位是秒取值范围是在0~3600秒之间。 在9i之后特别是到了10g中检查点已经相当的智能化了很少会成为I/O问题的原凶。9i中设置fast_start_mttr_target参数为你所期望的实例恢复时间系统将自动控制增量检查点的频率。比如你希望实例恢复可以在5分钟内完成你可以将此参数设置为300也就是300 当设置了fast_start_mttr_target后,fast_start_io_target这个参数将不再生效,从9I后fast_start_io_target这个参数被oracle废除了 Oracle 10g自动检查点调整 从Oracle 10g开始数据库可以实现自动调整的检查点使用自动调整的检查点Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据从而提高数据库的效率。因此及时数据库管理员设置了不合理的检查点相关参数Oracle仍然能够通过自动调整将数据库的Crash Recovery时间控制在合理的范围之内。 当FAST_START_MTTR_TARGET参数未设置自动检查点调整生效。 通常如果必须严格控制实例或节点恢复时间那么可以设置FAST_START_MTTR_TARGET为期望时间值如果恢复时间不严格控制那么可以不设置FAST_START_MTTR_TARGET参数从而启用Oracle 10g的自动调整特性 FAST_START_MTTR_TARGET ■如果此参数设置的值超出了硬件实际的限制比如你将它设置为60你期望无论在任何情况下数据库都可以在1分钟内完成实例恢复但根据数据库的脏块生成速度、存储设备的写性能1分钟内根本无法完成实例恢复。这时候Oracle会自动设置合适的fast_start_mttr_target参数值我们可以在参数文件中看到修正后的参数值也可以在V$instance_recovery视图中的Target_mttr列中看到实际的值 ■如果设置了FAST_START_MTTR_TARGET参数就不要用早期的一些参数容易引起冲突。 ■注意点如果将fast_start_mttr_target设置为非0 1将启用检查点自动调整机制。 2log_checkpoint_interval参数将被覆盖掉。 390% OF SMALLEST REDO LOG(Oarcle 内部机制)从上次切换后算起累计日志为 一个日志组大小的90%时做一次检查点切换。 4每3s查看checkpoint队列脏块的写出进度这个3秒是Oracle强调的增量检查点特性之 一。注意3s并不触发检查点它只是记录当时的检查点位置并将相关信息写入到 controlfile。 SQL show parameter fast_start_io NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ fast_start_io_target integer 0 SQL show parameter interval NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_checkpoint_interval integer 0 缺省情况下在Oracle 9i中FAST_START_IO_TARGET和LOG_CHECKPOINT_INTERVAL参数已经被设置为0. 在Oracle 9i R2开始Oracle引入了一个新的视图提供MTTR建议 SQL select * from 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 ESTD_TOTAL_IO_FACTOR------------------------ ------------- ----------- ----------------- ----------------------- ----------------- ----------------------- -------------- -------------------- 该视图评估在不同FAST_START_MATTR_TARGET设置下系统需要执行的I/O次数等操作。用户可以根据数据库的建议对FAST_START_MTTR_TARGET进行相应调整。 这个建议信息的收到Oracle 9i新引入的初始化参数statistics_level的控制当该参数设置为Typical或ALL时MTTR建议信息被收集 SQL show parameter statistics_levelNAME TYPE VALUE------------------------------------ ----------- ------------------------------statistics_level string TYPICAL 也可以通过v$statistics_level视图来查询MTTR_Advice的当前设置 SQL select * from v$statistics_level where STATISTICS_NAMEMTTR Advice;STATISTICS_NAME DESCRIPTION SESSION_STATUS SYSTEM_STATUS ACTIVATION_LEVEL STATISTICS_VIEW_NAME SESSION_SETTABLE---------------------------------------------------------------- -------------------------------------------------------------------------------- -------------- ------------- ---------------- ---------------------------------------------------------------- ----------------MTTR Advice Predicts the impact of different MTTR settings on number of physical I/Os ENABLED ENABLED TYPICAL V$MTTR_TARGET_ADVICE NO 90% OF SMALLEST REDO LOG oracle内部事实上还将重做日志末尾前面90%的位置设为检查点位置,这不是一个参数,这是oracle内部 规定的一个触发增量检查点的事件 fast_start_mttr_target,log_checkpoint_timeout,log_checkpoint_interval和90% OF SMALLEST REDOLOG 可以同时使用.考虑这样一种情况,如果上面的这些触发增量检查点的参数都被设置,并且在某一时刻,这几个参数一起被触发,但他们指定的Target RBA位置可能不尽相同,oracle将离日志末尾最近的那个位置认为检查点位置Checkpoint SCN可以从数据库中查询得到 select file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,yyyy-mm-dd hh24:mi:ss) cpt from v$datafile; select dbid,CHECKPOINT_CHANGE# from v$database; 数据库当前的实例恢复状态可以通过视图v$instance_recovery查询得到 SQLselect recovery_estimated_ios,actual_redo_blks,target_redo_blks,target_mttr,estimated_mttr from v$instance_recovery;RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR
---------------------- ---------------- ---------------- ----------- --------------72 333 3700 33 12系统计算出来的target_mttr为33秒,当前估算的恢复时间是12秒。
ESTIMATED_MTTR的估算值是基于Dirty Buffer 的数据量和日志块数量得出的这个参数值告诉我们如果此时数据库本亏那么进行实例恢复将会需要的时间。
TARGET_MTTR 代表的是期望的恢复时间通常改参数应该等于FAST_START_MTTR_TARGET参数设置值但是如果FAST_START_MTTR_TARGET参数定义的值极大或极小TARGET_MEER可能不等于FAST_START_MTTR_TARGET的设置。当ESTIMATED_MTTR接近或超过FAST_START_MTTR_TARGET参数设置
v$instance_recovery TARGET_MTTR时系统就会促发检查点
执行写出之后系统恢复信息将会重新计算
在繁忙的系统中可能会观察到ESTIMATED_MTTRTARGET_MTTR这可能是因为DBWR正忙于写出甚或出现Checkpoint不能及时完成的情况WRITES_AUTOTUNE字段数据就是指由于自动调整检查点执行的写出次数而CK_BLOCK_WRITES指的则是由于检查点写出的Block的数量。 其他 当运行alter tablespace ,datafile offline的时候; 运行alter tablespace、datafile offline的时候它们存在着一定的区别 alter datafile offline 在offline、online的时候系统将不会修改所有datafile的scn alter tablespace offline offline的事件就会修改scn号在online的时候系统也将修改该ts下的所有datafile的scn
