oracle检查点概念及说明解读.docx

1、oracle检查点概念及说明解读oracle 之检查点（Checkpoint ）检查点是一个数据库事件，它把修改的数据从高速缓存写入磁盘，并更新控 制文件和数据文件。检查点分为三类：1） 局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此 实例的全部脏缓存区写入数据文件。触发命令：svmrgrlalter system checkpo int local;这条命令显示的触发一个局部检查点。2） 全局检查点：所有实例（对应并行数据服务器）执行数据库所有数据文件的 一个检查点操作，属于此实例的全部脏缓存区写入数据文件。触发命令svrmgrlalter system checkpo

2、int global;这条命令显示的触发一个全局检查点。3） 文件检查点：所有实例需要执行数据文件集的一个检查点操作，如使用热备 份命令 alter tablespace USERS begin backup，或表空间脱机命令 alter tablespace USERS offline ，将执行属于USERS表空间的所有数据文件的一个 检查点操作。检查点处理步骤:1） 获取实例状态队列：实例状态队列是在实例状态转变时获得，ORACLE获得 此队列以保证检查点执行期间，数据库处于打开状态；2） 获取当前检查点信息：获取检查点记录信息的结构，此结构包括当前检查点 时间、活动线程、进行检查点处理的

3、当前线程、日志文件中恢复截止点的地址信 息；3） 缓存区标识：标识所有脏缓存区，当检查点找到一个脏缓存区就将其标识为 需进行刷新，标识的脏缓存区由系统进程DBWR进行写操作，将脏缓存区的内 容写入数据文件；4） 脏缓存区刷新：DBWR进程将所有脏缓存区写入磁盘后，设置一标志，标识 已完成脏缓存区至磁盘的写入操作。系统进程LGWR与CKPT进程将继续进行 检查，直至DBWR进程结束为止；5） 更新控制文件与数据文件。注：控制文件与数据文件头包含检查点结构信息。在两种情况下，文件头中的检查点信息（获取当前检查点信息时）将不做更新：1） 数据文件不处于热备份方式，此时ORACLE将不知道操作系统将何

4、时读文 件头，而备份拷贝在拷贝开始时必须具有检查点SCN ；ORACLE在数据文件头中保留一个检查点的记数器，在正常操作中保 证使用数 据文件的当前版本，在恢复时防止恢复数据文件的错误版本；即使在热备份方式 下，计数器依然是递增的；每个数据文件的检查点计数器，也保留在控制文件相 对应数据文件项中。2） 检查SCN小于文件头中的检查点SCN的时候，这表明由检查点产生的改动 已经写到磁盘上，在执行全局检查点的处理过程中，如果一个热备份快速检查点 在更新文件头时，则可能发生此种情况。应该注意的是，ORACLE是在实际进 行检查点处理的大量工作之前捕 获检查SCN的，并且很有可能被一条象热备份 命令a

5、lter tablespace USERS begin backup 进行快速检查点处理时的命令打 断。ORACLE在进行数据文件更新之前，将验证其数据一致性，当验证完成，即更 新数据文件头以反映当前检查点的情况；未经验证的数据文件与写入时出现错误 的数据文件都被忽略；如果日志文件被覆盖，则这个文件可能需要进行介质恢复, 在这种情况下，ORACLE系统进程DBWR将此数据文件脱机。检查点算法描述：脏缓存区用一个新队列链接，称为检查点队列。对缓存区的每一个改动，都有一 个与其相关的重做值。检查点队列包含脏的日志缓存区，这些缓存区按照它们在 日志文件中的位置排序，即在检查点队列中，缓存区按照它们的

6、低重做值进行排 序。需要注意的是，由于缓存区是依照第一次变脏的次序链接到队列中的，所以， 如果在缓存区写出之前对它有另外的改动，链接不能进行相应变更，缓存区一旦 被链接到检查点队列，它就停留在此位置，直到将它被写出为止。ORACLE系统进程DBWR在响应检查点请求时，按照这个队列的低重做值的升 序写出缓存区。每个检查点请求指定一个重做值，一旦DBWR写出的缓存区重 做值等于或大雨检查点的重做值，检查点处理即完成，并将记录到控制文件与数 据文件。由于检查点队列上的缓存区按照低重做值进行排序，而DBWR也按照低重做 值 顺序写出检查点缓存区，故可能有多个检查点请求处于活动状态，当DBWR写 出缓存

7、区时，检查位于检查点队列前端的缓存区重做值与检查点重做值的一致 性，如果重做值小于检查点队列前缓存区的低重做值的所有检查点请求，即可表 示处理完成。当存在未完成的活动检查点请求时，DBWR继续写出检查点缓存 区。算法特点：1） DBWR能确切的知道为满足检查点请求需要写那些缓存区；2） 在每次进行检查点写时保证指向完成最早的（具有最低重做 值的）检查点；3） 根据检查点重做值可以区别多个检查点请求，然后按照它们的顺序完成处理。1.检查点（Checkpoint ）的本质许多文档把Checkpint描述得非常复杂，为我们正确理解检查点带来了障碍， 结果现在检查点变成了一个非常复杂的问题。实际上，检

8、查点只是一个数据库事 件，它存在的根本意义在于减少崩溃恢复（Crash Recovery ）时间。当修改数据时，需要首先将数据读入内存中（Buffer Cache），修改数据的同时, Oracle会记录重做信息（Redo）用于恢复。因为有了重做信息的存在，Oracle 不需要在提交 时立即将变化的数据写回磁盘（立即写的效率会很低），重做（Redo）的存在也正是为了在数据库崩溃之后，数据就可以恢复。最常见的情况，数据库可以因为断电而Crash，那么内存中修改过的、尚未写入 文件的数据将会丢失。在下一次 数据库启动之后，Oracle可以通过重做日志（Redo）进行事务重演，也就是进行前滚，将数据库

9、恢复到崩溃之前的状态， 然后数据库可以打开提供使用，之后Oracle可以将未提交的数据进行回滚。在这个过程中，通常大家最关心的是数据库要经历多久才能打开。也就是需要读取多少重做日志才能完成前 滚。当然用户希望这个时间越短越好，Oracle也正 是通过各种手段在不断优化这个过程，缩短恢复时间。检查点的存在就是为了缩短这个恢复时间。当检查点发生时(此时的SCN被称为CheckPoi nt SCN ), Oracle会通知DBWR 进程，把修改过的数据，也就是Checkpoint SCN 之前的脏数据(Dirty Data ) 从Buffer Cache写入磁盘，当写入完成之后，CKPT进程更新控制

10、文件和 数据 文件头，记录检查点信息，标识变更。Oracle SCN的相关知识可以参考我的另外一篇文章：DBA入门之认识OracleSCN (System Change Number )Checkpoi nt SCN 可以从数据库中查询得到：file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,yyyy-mm-dd hh24:mi:ss) cpt from v$datafile;FILE# CHECKPOINT_CHANGE# CPT1913306 2011 - 11- 16 16:06:062913306 2011 - 11- 16 16:06:0

11、63913306 2011 - 11- 16 16:06:064913306 2011 - 11- 16 16:06:06SQL select dbid,CHECKPOINT_CHANGE# from v$database;DBID CHECKPOINT_CHANGE#1294662348 913306在检查点完成之后，此检查点之前修改过的数据都已经写回磁盘，重做日志文件 中的相应重做记录对于崩溃/实例恢复不再有用。下图标记了3个日志组，假定在T1时间点，数据库完成并记录了最后一次检查 点，在T2时刻数据库Crash。那么在下次数据库启动时，T1时间点之前的Redo 不再需要进行恢复，Orac

12、le需要重新应用的就是时间点T1至T2之间数据库生 成的重做日志（Redo）星窗戍检畳盘位 Crash苴上图可以很轻易地看出来，检查点的频率对于数据库的恢复时间具有极大的影 响，如果检查点的频率高，那么恢复时需要应用的重做日志就相 对得少，检查时 间就可以缩短。然而，需要注意的是，数据库内部操作的相对性极强，国语平凡 的检查点同样会带来性能问题，尤其是更新频繁的数据库。所以数据库的优化是 一个系统工程，不能草率。更进一步可以知道，如果Oracle可以在性能允许的情况下，使得检查点的SCN 主键逼近Redo的最新更新，那么最终可以获得一个最佳平衡点，使得Oracle可 以最大化地减少恢复时间。为

13、了实现这个目标，Oracle在不同版本中一直在改 进检查点的算法。2.常规检查点与增量检查点为了区分，在 Oracle8之前，Oracle实时的检查点通常被 称为常规检查点(Con ve ntio nal Checkpoi nt ),这类检查点按一定的条件出发(log_checkpoint_interval 、log_checkpoint_timeout 参数设置及 log switch等条件出发)。从 Oracle 8 开始，Oracle 引入了增量检查点(Inctrmental Checkpoint )的概念。和以前的版本相比，在新版本中，Oracle主要引入了检查点队列(Checkpoi

14、nntQueue )机制，在数据库内部，每一个脏数据块都会被移动到检查点队列，按照Low RBA的顺序(第一次对比数据块修改对应的Redo Byte Address)来排 列，如果一个数据块进行过多次修改，该数据库在检查点队列上的顺序并不会发 生变化。当执行检查点时，DBWR从检查点队列按照Low RBA的顺序写出，实例检查 点因此可以不断增进、阶段性的，CKPT进程使用非常轻量级的控制文件更新 协议，将当前的最低RBA写入控制文件。因为增量检查点可以连续地进行，因此检查点RBA可以比常规检查点更接近数 据库的最后状态，从而在数据库的实例恢复中可以极大地减少恢复时间。而且，通过增量检查点，DB

15、WR可以持续进行写出，从而避免了常规检查点出 发的峰值写入对于I/O的国度征用，通过下图可以清楚地看到这一改进的意义。1DBWR写岀量 ILCheckpoint时间在数据库中，增量检查点是通过Fast-Start Checkpointing 特性来实现的，从Oracle 8i 开始，这一特性包含了 Oracle 企业版的 Fast-Start Fault Recovery组件之中，通过查询v$option视图，了解这一特性：剧 ISQLselect*from v$version where rownum col parameter for a30SQL col value for a20SQL

16、select*from V$optio nwhere Parameter=Fast-Start Fault Recovery;PARAMETER VALUEFast-Start Fault Recovery TRUE该组件包含3个主要特性，可以加快系 统在故障后的恢复，提高系统的可用性。Fast-Start Checkpo in ti ng;Fast-Start On-Dema nd Rollback;Fast-Start Parallel Rollback;Fast-Start Checkpoi nting 特性在 Oracle 8i 中 主要通过参数FAST_START_IO_TARGET

17、 来实现，在 Oracle 9i 中，Fast-StartCheckpointing 主要通过参数 FAST_START_MTTR_TARGET 来实现。3.FAST START MTTR TARGETFAST_START_MTTR_TARGET 参数从Oracle 9i开始被引入，该参数定义 数据库进行Crash恢复的时间，单位是秒，取值范围是在03600秒之间。在Oracle 9i中，Oracle推荐设置这个参数代替FAST_START_IO_TARGE 、 LOG_CHECKPOINT_TIMEROUT 及 LOG_CHECKPOINT_INSTERVAL 参 数。缺省情况下，在 Ora

18、cle 9i 中，FAST_START_IO_TARGET 和LOG_CHECKPOINT_INTERVAL 参数已经被设置为 0.SQL show parameter fast_start_ioNAME TYPE VALUEfast_start_io_target in teger 0SQL show parameter in terval NAME TYPE VALUE在Oracle 9i R2开始，Oracle引入了一个新的视图提供MTTR建议:SQL select * from v$mttr_target_advice;MTTR_TARGET_FOR_ESTIMATE ADVICE_S

19、TATUS DIRTY_LIMITESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTORESTD_TOTAL_WRITES ESTD_TOTAL_WRITE_FACTORESTD_TOTAL_IOS ESTD_TOTAL_IO_FACTOR该视图评估在不同FAST_START_MATTR_TARGET 设置下，系统需要执行的I/O 次数等操作。用户可以根据数据库的建议，对 FAST_START_MTTR_TARGET 进行相应调整。这个建议信息的手机收到Oracle 9i新引入的初始化参数statistics_level 的控 制，当该参数设置为Typical或AL

20、L时，MTTR建议信息被手机:M31SQL show parameter statistics_levelNAME TYPE VALUE帕I也可以通过v$statistics_level 视图来查询 MTTR_Advice 的当前设置：匿SQL select * from v$statistics_level where STATISTICS_NAME=MTTRAdvice;STATISTICS_NAME DESCRIPTION SESSION_STATUSSYSTEM_STATUS ACTIVATION_LEVEL STATISTICS_VIEW_NAMESESSION_SETTABLEnu

21、 mberTYPICAL查询得到:MTTR Advice Predicts the impact of differe nt MTTR sett in gs on of physical I/Os ENABLED ENABLEDV$MTTR_TARGET_ADVICE NO&数据库当前的实例恢复状态可以通过视图v$instance_recovery阳ISQL select * from v$instance_recovery;RECOVERY_ESTIMATED_IOS 53ACTUAL_REDO_BLKS 376TARGET_REDO_BLKS 184320LOG_FILE_SIZE_RED

22、O_BLKS 184320LOG_CHKPT_TIMEOUT_REDO_BLKSLOG_CHKPT_INTERVAL_REDO_BLKSTARGET_MTTR 0ESTIMATED_MTTR 18CKPT_BLOCK_WRITES 27OPTIMAL_LOGFILE_SIZEESTD_CLUSTER_AVAILABLE_TIMEWRITES_MTTR 0WRITES_LOGFILE_SIZE 0WRITES_LOG_CHECKPOINT_SETTINGS 0WRITES_OTHER_SETTINGS 0WRITES_AUTOTUNE 104WRITES_FULL_THREAD_CKPT 0从v

23、$instance_recovery 视图，可以看到 当前数据库估计的平均恢 复时间(MTTR)参数：ESTIMATED_MTTR 。ESTIMATED_MTTR 的估算值是基于Dirty Buffer 的数据量和日志块数量得 出的，这个参数值告诉我们，如果此时数据库本亏，那么进行实例恢复将会需要 的时间。在V$instance_revovery 视图中，TARGET_MTTR 代表的是期望的恢 复时间， 通常改参数应该等于FAST_START_MTTR_TARGET 参数设置值(但是如果FAST_START_MTTR_TARGET 参数定义的值极大或极小,TARGET_MEER可能不等于FA

24、ST_START_MTTR_TARGET 的设置)。当 ESTIMATED_MTTR 接近或超过 FAST_START_MTTR_TARGET 参数设 置(v$instance_recovery TARGET_MTTR )时，系 统就会促发检查点，执 行写出之后，系统恢复信息将会重新计算： View CodeRECOVERY_ESTIMATED_IOS 24ACTUAL_REDO_BLKS 43TARGET_REDO_BLKS 184320LOG_FILE_SIZE_REDO_BLKS 184320LOG_CHKPT_TIMEOUT_REDO_BLKSLOG_CHKPT_INTERVAL_RE

25、DO_BLKSTARGET_MTTR 0ESTIMATED_MTTR 18CKPT_BLOCK_WRITES 73OPTIMAL_LOGFILE_SIZEESTD_CLUSTER_AVAILABLE_TIMEWRITES_MTTR 0WRITES_LOGFILE_SIZE 0WRITES_LOG_CHECKPOINT_SETTINGS 0WRITES_OTHER_SETTINGS 0WRITES_AUTOTUNE 183WRITES_FULL_THREAD_CKPT 0在繁忙的系 统中，可能会观察到ESTIMATED_MTTRTARGET_MTTR ,这 可能是因为DBWR正忙于写出，甚或出现

26、Checkpoint不能及时完成的情况。4. Oracle 10g 自动检查点调整从Oracle 10g开始，数据库可以实现自动调整的检查点，使用自动调整的检查点，Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据，从而提高数据库的效率。因此，及 时数据库管理员设置了不合理的检查点相关参数,Oracle仍然能够通过自动调整将数据库的Crash Recovery 时间控制在合理的 范围之内。当FAST_START_MTTR_TARGET 参数未设置，自动检查 点调整生效。通常，如果必须严格控制实例或节点恢复时间，那么可以设置FAST_START_MTTR_TARGET 为期望时间

27、值；如果恢复时间不严格控制， 那么可以不设置FAST_START_MTTR_TARGET 参数，从而启用Oracle 10g 的自动调整特性。当取消FAST_START_MTTR_TARGET 参数设置之后： View CodeSQL show parameter fast_start_mttrNAME TYPE VALUEfast_start_mttr_target in teger 0在启动数据库的时候，可以从alter文件中看到如下信息: View CodeThu Nov 17 20:27:23 2011MTTR advisory is disabled because FAST_STA

28、RT_MTTR_TARGET isnot set检查v$instance_recovery 视图，可以发现Oracle 10g 的改变： View CodeSQL select * from v$instance_recovery;RECOVERY_ESTIMATED_IOS 53ACTUAL_REDO_BLKS 376TARGET_REDO_BLKS 184320LOG_FILE_SIZE_REDO_BLKS 184320LOG_CHKPT_TIMEOUT_REDO_BLKSLOG_CHKPT_INTERVAL_REDO_BLKSFAST_START_IO_TARGET_REDO_BLKST

29、ARGET_MTTR 0ESTIMATED_MTTR 18CKPT_BLOCK_WRITES 27OPTIMAL_LOGFILE_SIZEESTD_CLUSTER_AVAILABLE_TIMEWRITES_MTTR 0WRITES_LOGFILE_SIZE 0WRITES_LOG_CHECKPOINT_SETTINGS 0WRITES_OTHER_SETTINGS 0WRITES_AUTOTUNE 104WRITES_FULL_THREAD_CKPT 0在以上视图中，WRITES_AUTOTUNE 字段数据就是指由于自动调整检查点执 行的写出次数，而CK_BLOCK_WRITES 指的则是由于

30、检查点写出的Block的 数量。关于检查点的机制问题，我们侧重介绍了原理，至于具体的算法 实现，不需要去 追究过多，只要明白了这个原理性的规则，理解Oracle就会变成轻松的事情。Oracle的算法改进是一种优化，对于数据库的调整优化也不外如此，借鉴Oracle 的优化对于理解和优化Oracle数据库都具有极大的好处。5.从控制文件获取检查点信息在控制文件的转储中，可以看到关于检查点进程进度的记录：*(size = 8180, compat size = 8180, sect ion max = 11, secti on in-use = 0, last-recid= 0, old-rec n

31、o = 0, last-rec no = 0)(exte nt = 1, blk no = 2, nu mrecs = 11)THREAD #1 - status:0x2 flags:0x0 dirty:34 low cache rba:(0x23.19d5.0) on disk rba:(0x23.1a68.0) on disk scn: 0x0000.000d847d 11/14/2011 15:25:37 resetlogs scn: 0x0000.0006ce7b 11/10/2011 22:40:23 heartbeat: 767211774 mou nt id: 1294947385THREAD #2