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 SCN），Oracle会通知DBWR进程，将数据缓冲区里的脏数据块，也就是Checkpoint SCN之前的脏数据（Dirty Data）从Buffer Cache写入磁盘，当写入完成之后，CKPT进程更新控制文件和数据文件头，记录检查点信息，标识变更。
作用	保证数据库的一致性 这是指将脏数据写出到硬盘，保证内存和硬盘上的数据是一样的 缩短实例恢复的时间 ■实例恢复要把实例异常关闭前没有写到硬盘的脏数据通过日志进行恢复。 ■如果脏块过多，实例恢复的时间也会过长，检查点的发生可以减少脏块的数量，从而减少实例 恢复的时间。 ■通过LRBA（LOW REDO BUFFER ADRESS），HRBA（HIGH 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   648319278 CPDRT列是检查点队列中的脏块数目. 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_alert=true; 系统已更改。 步骤2:将增量检查点的切换频率定为300秒. log_checkpoint_timeout 该参数用于表示检查点位置和重做日志尾之间的时间间隔,以秒为单位, 默认情况下是1800秒, 这个参数实际上表示了脏块保持脏状态的最长时间。 如果它被定为1800秒,没有脏块保持1800秒后,还是为脏 LOG_CHECKPOINT_INSTERVAL 该参数是表示检查点位置和重做日志末尾的块的数量.以OS表示. LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL参数， 根据这个参数，Oracle计算出在内存中累积的dirty buffer所需 的日志恢复时间，如果到达该参数指定的时间，则增量检查点进程 被触发。该参数如果为0，ORACLE则会根据，Oracle将根据产生脏 块的速度、存贮硬件的性能自动调节检查点的频率，让DBWN进程自 身尽量减少写入量，这样虽然实现了性能最大化，但实例恢复时间 可能会比较长 SQL> alter system set log_checkpoint_timeout=300;[单位是秒] 系统已更改。   局部检查点 触发命令： SQL>alter 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将不知道操作系统将何时读文件头，而备份拷贝在拷贝开始时必须具有检查点SCN；ORACLE在数据文件头中保留一个检查点的记数器，在正常操作中保证使用数据文件的当前版本，在恢复时防止恢复数据文件的错误版本；即使在热备份方式下，计数器依然是递增的；每个数据文件的检查点计数器，也保留在控制文件相对应数据文件项中。 2）检查SCN小于文件头中的检查点SCN的时候，这表明由检查点产生的改动已经写到磁盘上，在执行全局检查点的处理过程中，如果一个热备份快速检查点在更新文件头时，则可能发生此种情况。应该注意的是，ORACLE是在实际进行检查点处理的大量工作之前捕获检查SCN的，并且很有可能被一条象热备份命令 alter tablespace USERS begin backup进行快速检查点处理时的命令打断。   ORACLE在进行数据文件更新之前，将验证其数据一致性，当验证完成，即更新数据文件头以反映当前检查点的情况；未经验证的数据文件与写入时出现错误的数据文件都被忽略；如果日志文件被覆盖，则这个文件可能需要进行介质恢复，在这种情况下，ORACLE系统进程DBWR将此数据文件脱机
	如果FAST_START_MTTR_TARGET<>0，v$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继续写出检查点缓存区。   算法特点： 1）DBWR能确切的知道为满足检查点请求需要写那些缓存区； 2）在每次进行检查点写时保证指向完成最早的（具有最低重做值的）检查点； 3）根据检查点重做值可以区别多个检查点请求，然后按照它们的顺序完成处理
参数与命令	在数据库中，增量检查点是通过Fast-Start Checkpointing特性来实现的，从Oracle 8i开始，这一特性包含了Oracle企业版的Fast-Start Fault Recovery组件之中 select * from V$option where Parameter='Fast-Start Fault Recovery'; 该组件包含3个主要特性，可以加快系统在故障后的恢复，提高系统的可用性。 Fast-Start Checkpointing 特性在Oracle 8i中主要通过参数FAST_START_IO_TARGET来实现 Fast-Start Checkpointing Fast-Start On-Demand Rollback Fast-Start Parallel Rollback fast_start_io_target 该参数用于表示数据库发生Instance Recovery 的时候需要产生的IO总数,他通过v$filestat的AVGIOTIM来估算的.比如我们一个数据库发生Instance Crash后需要在10分钟内恢复完毕,假定OS的IO每秒为500个,那么这个数据库发生Instance Recovery的时候大概产生500*10*60=30,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）将启用检查点自动调整机制。     2）log_checkpoint_interval参数将被覆盖掉。     3）90% 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_level NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ statistics_level string TYPICAL 也可以通过v$statistics_level视图来查询MTTR_Advice的当前设置： SQL> select * from v$statistics_level where STATISTICS_NAME='MTTR 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查询得到： SQL>select 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_MTTR>TARGET_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