1.检查点概念--chkpoint
检查点是一个数据库事件，存在的意义在于减少崩溃恢复crash recovery时间.
检查点事件由后台进程CKPT触发，当检查点发生时，CKPT通知DBWR进程将脏数据库dirtybuffer写出到数据文件上，更新数据文件头及控制文件上的检查点信息。
数据文件头的SCN是CHECKPOINT SCN.
1、关于checkpoint的概述
checkpoint是oracle在数据库一致性关闭、实例恢复和oracle基本操作中不可缺少的机制，包含以下相关的含义：
A、检查点的位置（checkpoint position）为一种数据结构，在redo流中记录的SCN号是在进行数据库实例恢复起始位置。
检查点的位置由在数据缓冲池中存在的最老的脏数据位置决定，检查点的位置相当于一个指向redo流的指针，并且检查点的信息存储在控制文件和数据文件的头中。
B、将数据缓冲区中修改后的脏数据写入到磁盘中。
2、checkpoint的目的
A、当实例恢复或者介质恢复时，减少恢复所需要的时间
B、确保在数据缓冲区中的脏数据已经写入到磁盘当中
C、确保在进行数据库一致性关闭的时候所有提交的数据都写入到磁盘当中
3、什么时候数据库启动checkpoint
CKPT进程负责将checkpoint的信息写入到数据文件头中和控制文件中，包括以下几种类型的检查点
A、thread checkpoint（线程检查点或者数据库检查点）
数据库将所有在数据缓冲区内由redo修改过的数据写入到磁盘中在某些动作之前，这个线程检查点在所有的实例中的集合称之为数据库检查点（database checkpoint），线程检查点发生在下列情况下：
——数据库一致性关闭的时候
——ALTER SYSTEM CHECKPOINT语句的时候
——在线日志切换的时候
——ALTER DATABASE BEGIN BACKUP语句的时候
B、tablespace and data file checkpoint（表和数据文件检查点）
数据库将所有在数据缓冲区内由redo修改过的数据写入到磁盘中在具体动作之前，表空间的检查点是数据文件检查点的集合，每个数据文件都在这个表空间之内，此种检查点发生在以下情况：
——将一个表空间设置为只读的方式
——将一个表空间设置为offline
——数据文件大小变化的时候
——执行ALTER TABLESPACE BEGIN BACKUP的时候
C、incremental checkpoint（增量检查点）
增量检查点是线程检查点的一种，是为了避免在线日志切换的时候需要写入大量的脏数据到磁盘中，DBWn每三秒检查一次看是否有数据是否要写入到磁盘当中，当DBWn进程需要将脏数据写入到磁盘中时，从而推进检查点的位置，导致CKPT进程将检查点位置信息写入到控制文件中，但是不会写入到数据头文件中。
D、其他的检查点包括实例和介质恢复检查点、检查点当schema对象被dropped和truncated的时候
4、相关进程CKPT
CKPT进程的全称为checkpoint process，负责：
A、更新控制文件和数据头文件中的检查点信息
B、通知DBWn进程将脏数据写入磁盘中
检查点信息包括：
A、检查点位置
B、SCN
C、在线日志文件中开始恢复的位置
CKPT进程不负责将脏数据写入到磁盘中，不负责将redo缓冲区的数据写入到在线日志文件中
DBWn进程负责将脏数据存盘，LGWR进程负责将redo缓冲区中的书籍存盘
检查点工作原理：
在数据库中，进行数据修改时，需要先将数据读和内存中buffer cache,修改数据同时，ORACLE会记录重做redo信息用于恢复，有了重做日志信息存在，ORACLE不需要在事务提交时commit立刻将变化的数据写回磁盘，因为立刻写效率会低。重做信息存在也为数据崩溃后，数据可以恢复。如断电，内存中修改过未写入数据文件的数据丢失，下一次数据库启动时，可以通过重做日志进行事务重演（不管是否提交），即前滚。将数据库恢复至崩溃前状态，然后数据库可以打开提供使用，之后ORACLE将未提交的事务回滚。
检查点存在是为了缩短上述数据恢复的时间。
当检查点发生时，此时的SCN称为checkpoint scn,ORACLE会通知DBWR，把修改过的数据，即此checkpoint scn之前的脏数据dirty data从buffer cache写入磁盘，写入完成后，CKPT进程会相应更新控制文件和数据文件头，记录此检查点信息，标识变更。
检查点完成后，此检查点之前修改过后 数据都已经写出到数据文件，重做日志中的相应重做记录对于实例恢复已经无用（物理恢复有用）。
######################################################################
2.增量检查点概念 incremental checkpoint 及CKPTQ,FILEQ
检查点队列，checkpoint queue,CKPTQ;
在数据库内部，每个脏数据块会被记录到检查点队列，按LRBA（LOW RBA 第一次修改数据块对应的redo block address，后面修改的RBA称为HRBA）顺序排列，如果一个数据块多次修改，该数据块在检查点队列上顺序不变化。非脏块的buffer header中的CKPTQ信息为空。
执行增量检查点时，DBWR从检查点队列按照LOW RBA顺序写出，先修改的数据可以被按优先顺序写出，实例检查点因此可以不被增进。
同时CKPT进程阶段性使用轻量级控制文件更新协议将当前最低RBA写入控制文件，CKPT在进行轻量级更新时，不改写控制文件中数据文件中检查点信息以及数据文件头信息，只记录控制文件检查点SCN，controlfile checkpointed at scn 并根据增量检查点写出增进RBA信息。
通过增量检查点，数据库可以将全部写出改为增量渐进写出，从而极大减少对于数据库性能的影响，而检查点队列进一步将RBA和检查点关联起来，从而可以通过检查点确定恢复的起点。
与CKPTQ相关的是：文件检查点队列 file queue FILEQ与对象队列Obj-Q
文件检查点提高了表空间检查点TABLESPACE CHECKPOINT的性能，每个dirty buffer同时链接到CKPTQ和FILEQ，CKPTQ包含实例所有需要执行检查点的BUFFER，FILEQ包含属于特定文件需要执行检查点的BUFFER,每个文件都包含一个文件队列，在执行表空间检查点请求时使用FILEQ。--表空间OFFLINE会触发表空间检查点。3.CKPT进程在增量检查点中的作用：
CKPT进程监控着检查点队列的长度，当检查点队列长度达到一定限制时，CKPT会通知DBWR写脏块CKPT会根据参数的设置和I/O的速度以及繁忙程度,计算出来一个Target rba(目标rba),DBWR会沿着检查点队列,将所有Target rba之前的脏块刷新到磁盘.当CKPT通知完DBWR Target rba后,CKPT的任务就结束了.并不会等待DBWR写完所有的Target rba之前的脏块.
通知DBWR写脏块,这是CKPT的任务之一,CKPT另一个任务,就是每3秒,检测一次DBWR的写进度.
检查点队列最前面的块被称为检查点位置.DBWR是沿着检查点队列写脏块的,CKPT每3秒钟查看一下DBWR沿检查点队列写到了哪里,并且将这个位置设置为检查点位置.也就是说检查点位置之前的块,都是已被DBWR刷新到磁盘上的块.
这个3秒一次检查DBWR进度的工作,也是CKPT的一个重要的任务.CKPT每3秒一次将检查点位置记录进控制文件,当然同时被记录进控制文件的还有'心跳'等其他信息.
CKPT每3秒一次的工作和CKPT定期触发DBWR,这两项操作合一起被称为--增量检查点.
4.dbwr 写CKPTQ上脏块的方式：
在检查点队列中，脏块根据按LRBA顺序排列，DBWR每到一定的时机，被触发。硬件能力、脏块数、Redo数三个指标，是DBWR是否写脏块的依据。
DBWR什么时候（多久）判断一次这三个值标：3s
也就是：DBWR 3秒醒来，依据三个指标判断是否触发------“增量检查点写”
5.fast_start_mttr_target与增量检查点
一、关于FAST_START_MTTR_TARGET概念： --此段百度哈哈
是一个加快实例恢复的参数，我们可以根据服务级别来定义一个合理的、可接受的值，该值的单位为秒。比如设定为60s，即2分钟。假定该值处于合理的情况之下，则一旦实例崩溃，在60s以内实例应当能够被恢复。合理即是该值不能太大，也不能太小。太大则实例恢复所需的时间较长，太小则导致大量数据的及时写入，增加了系统的I/O。
影响实例恢复时间长短的主要因素即是从最近检查点位置到联机重做日志尾部之间的距离。距离越长则所需要的cache recovery 和undo、redo的时间越长。所以如何有效的缩短最近检查点位置与联机重做日志尾部之间的距离，这正是FAST_START_MTTR_TARGET的目的。
关于检查点的触发条件有很多，比如日志切换、数据库shutdown、开始结束备份表空间等。检查点的分类也很多，比如完全检查点、部分检查点、增量检查点等。
FAST_START_MTTR_TARGET的值实际上也是触发检查点的一个触发条件。当内存中产生的dirty buffer所需的恢复时间(estimated_mttr)如果到达FAST_START_MTTR_TARGET的指定时间，则检查点进程被触发。检查点进程一旦被触发，将通知DBWn进程将按检查点队列顺序将脏数据写入到数据文件，从而缩短了最后检查点位置与联机重做日志间的距离，减少了实例恢复所需的时间。
二、FAST_START_MTTR_TARGET参数的设置
9i之后（包括9i):fast_start_mttr_target：以实例恢复时间为单位（硬件能力、脏块数、Redo数）10G之后，fast_start_mttr_target默认值为0，即开启自调节检查点：self tune checkpoint ，自调节检查点的受影响因素有：硬件能力、脏块数、Redo数
自调节检查点对应隐含参数：_disable_selftune_checkpointing:
_disable_selftune_checkpointing Disable self-tune checkpointing FALSE
SYS@ bys3>show parameter statistics_level --此参数为typical 或者all，再加上FAST_START_MTTR_TARGET 设置为非零值就启用MTTR Advisory
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL
SYS@ bys3>show parameter mttr
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 0
从alert日志中数据库启动时的信息可以发现：
[oracle@bys3 ~]$ cat alert_bys3.log |grep MTTR
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
显式的设置alter system set FAST_START_MTTR_TARGET=0会关闭自动调节，重启数据库在alter日志中可以发现：
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
当FAST_START_MTTR_TARGET显示设为非零
SYS@ bys3>alter system set fast_start_mttr_target=25;
即： statistics_level参数为typical 或者all，再加上FAST_START_MTTR_TARGET 设置为非零值就启用MTTR Advisory
此时alert日志中不会有MTTR信息--因为已经正常启动MTTR Advisory
三、关于启动MTTR Advisory时v$instance_recovery;视图的使用： --未开启MTTR Advisory时此视图内容为空。
SYS@ bys3>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
------------------------ ----------- ----------------- ----------------------- ----------------- -----------------------
18 1067 57 1 806 1
17 1000 57 1 806 1
19 1268 57 1 806 1
20 1507 57 1 806 1
SYS@ bys3>select target_mttr,estimated_mttr from v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
20 12
--mttr_target_for_estimate有一个值为的最接近设定的目标时间20，以及由系统计算出的的target_mttr时间20
--同时也给出了几组不同的mttr_target值及dirty_limit,cache_write,io 等来供选择，设定合适的mttr值
 |
|
|
适用于:
Oracle Database - Enterprise Edition本文档所含信息适用于所有平台
用途
本文档旨在使数据库管理员更好地了解增量检查点（Checkpoint），并对检查点（Checkpoint）优化所用的下列四个初始化参数进行了描述：
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
此外，本文档还介绍了如何解释和处理检查点错误：ALERT.LOG 文件中报告的“Checkpoint not Complete（检查点未完成）”和“Cannot Allocate New Log（无法分配新日志）”。
详细信息
目录：
1. 什么是检查点？
2. 检查点和性能
3. 与增量检查点相关的参数
4. Redo（重做）日志和检查点
5. 了解检查点错误消息（“Cannot allocate new log”和“Checkpoint not complete”）
6. Oracle 版本信息
7. 使用 Statspack 确定检查点问题
检查点优化和错误处理
检查点是一种将内存中的已修改数据块与磁盘上的数据文件进行同步的数据库事件。通过Checkpoint Oracle 确保了被 transaction 修改过数据可以被同步至磁盘。Oracle transaction 提交的时候不会将已修改数据块同步写入磁盘上。检查点有两个用途：(1) 确保数据一致性，和 (2) 实现更快的数据库恢复。如何更快地恢复？由于直至检查点生成时所有的数据库更改均已记录在数据文件中，因此无需再应用先于检查点的 redo 日志条目。检查点必须确保高速缓存中所有已修改的缓冲数据均已切实写入到相应的数据文件中，以避免在发生崩溃（实例或磁盘故障）时可能会出现的数据丢失。
Oracle 只有在特定条件下才会将脏缓存写入磁盘：
- shadow process 需要扫描的数据块个数超过 db_block_buffers 参数的四分之一。
- 每三秒钟。
- 生成一个检查点时。检查点通过五种类型的事件来实现：
- 每次切换 redo 日志文件时。
- 达到 LOG_CHECKPOINT_TIMEOUT 的延迟时。
- 当前 redo 日志文件中已存在了大小为 （LOG_CHECKPOINT_INTERVAL* OS块的大小（bytes））的数据。
- 直接由 ALTER SYSTEM SWITCH LOGFILE 命令实现。
- 直接使用 ALTER SYSTEM CHECKPOINT 命令实现。
在检查点期间会发生以下操作：
- DBWR 将缓冲区缓存中所有已修改的数据库块写回到数据文件中，
- 检查点进程 (ckpt) 更新所有数据文件的文件头，以反映上一个检查点发生的时间 (SCN)
检查点的优化常常会使数据库管理员左右为难。频繁的检查点会实现更快的数据库恢复，但也会导致数据库性能降低。那么，DBA 如何解决这一问题呢？根据数据库中的数据文件数量，检查点将会是一种高度占用资源的操作，因为所有数据文件头在检查点期间都会被冻结。关于检查点的频率设置，需要对性能进行权衡。检查点频率越高，就能在数据库崩溃后更快地实现恢复。这也是为什么一些不太能忍受意外系统停机的客户现场常常会选择此选项的原因。但是，在很多情况下，频繁的检查点可能会导致性能降低，这使得上述观点并不能完全站稳脚跟。 我们假设数据库已启动，且有 95% 的时间处于运行状态，剩下 5% 未运行时间是由于出现偶发的实例崩溃或硬件故障，需要进行数据库恢复。对于大多数的客户现场而言，优化 95% 的性能相比于极少的 5% 停机时间要更具意义。
本文档假设性能是您的首要考虑事项，并由此给出相应的建议。因此，您的目标是通过优化尽量减少检查点的频率。
优化检查点涉及到下面四个关键初始化参数：
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT下面将详细讨论这些参数。
同时，还针对alert日志中出现的“checkpoint not complete”消息给出了处理建议，这些消息说明redo 日志和检查点需要优化。
3. 与增量检查点相关的参数
注意：日志文件切换将始终覆盖由以下参数引起的检查点。
- FAST_START_MTTR_TARGET
自 Oracle 9i 以来，FAST_START_MTTR_TARGET 参数已成为优化增量检查点目标的首选方法。通过 FAST_START_MTTR_TARGET，您可以指定数据库执行单实例的崩溃恢复所要花费的秒数。基于内部统计信息，增量检查点会自动调整检查点目标，以满足 FAST_START_MTTR_TARGET 的要求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 显示当前预计的平均恢复时间 (MTTR)（以秒为单位）。即使未指定 FAST_START_MTTR_TARGET，也同样会显示此值。
V$INSTANCE_RECOVERY.TARGET_MTTR 显示由系统强制执行的有效 MTTR 目标（以秒为单位）。
V$MTTR_TARGET_ADVICE 显示在当前的 MTTR 设置下由当前的工作负载产生的 I/O 数量，以及在其他 MTTR 设置下将由当前的工作负载产生的预计 I/O 数量。此视图可帮助用户在运行时性能和设置 FAST_START_MTTR_TARGET 以实现快速恢复之间进行权衡。
- LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_INTERVAL 参数指定增量检查点目标应滞后于当前日志尾的最大 redo 块数量。
如果指定了 FAST_START_MTTR_TARGET，就不应设置 LOG_CHECKPOINT_INTERVAL 或将其设置为 0。在大多数 Unix 系统上，操作系统块大小都是 512 字节。
也 就是说，将 LOG_CHECKPOINT_INTERVAL 的值设置为 10,000 就意味着增量检查点目标相对于当前日志尾的滞后不得超过 5,120,000 (5M) 字节。以此计算，如果 redo 日志的大小为 20M，则会对每个日志产生 4 个检查点。
LOG_CHECKPOINT_INTERVAL 会影响检查点的发生时间，这意味着应特别注意此参数的设置，保持其随 redo 日志文件的大小变化而更新。检查点的频率是影响数据库从意外故障中恢复所需时间的因素之一。检查点之间的间隔越长，则在发生系统崩溃时，数据库恢复所需的 时间就越长。检查点间隔越短意味着数据库的恢复速度越快，但是代价是检查点操作会消耗更多的资源。
此参数还会影响在恢复的前滚阶段期间完成数据库恢复操作所需的时间。实际的恢复时间取决于此时间，以及其他因素，例如故障类型（实例或系统崩溃、介质故障等）以及需要应用的归档 redo 日志数量。
- LOG_CHECKPOINT_TIMEOUT
LOG_CHECKPOINT_TIMEOUT 参数指定增量检查点目标应滞后于当前日志尾的最长秒数。
换句话说，它指定缓冲区缓存中的脏缓存可以保持脏状态的时间。
检查点频率影响数据库从意外故障中恢复所需的时间。检查点之间的间隔越长，数据库恢复所需的时间就越多。
Oracle 建议使用 LOG_CHECKPOINT_INTERVAL 而不是 LOG_CHECKPOINT_TIMEOUT 来控制检查点间隔，后者会每“n”秒启动一次检查点，而不管事务频率。这可能会导致在事务量变化的情况下出现不必要的检查点。只要可能，就必须避免不必要的检查点，以实现最佳性能。
许多人会有这样一种误解：将 LOG_CHECKPOINT_TIMEOUT 设置为给定值之后，系统就会按该间隔启动日志切换，从而启用用于stand-by数据库配置的恢复窗口。日志切换会引起检查点，但检查点并不会引起日志切换。引起日志切换的唯一方式是使用 ALTER SYSTEM SWITCH LOGFILE 进行手动操作或重新调节 redo 日志大小，以引起更为频繁的切换。这由操作系统块而非时间间隔控制。
在线 redo 日志的大小对性能和恢复至关重要。
有关 redo 日志和检查点的信息，请参考以下其他部分。
- LOG_CHECKPOINTS_TO_ALERT
通过 LOG_CHECKPOINTS_TO_ALERT，您可以将检查点记录到alert日志中。
这样做有助于确定检查点是否按所需频率发生。
在 Oracle9i 之前，此参数为静态参数。
Oracle 通常建议将此参数设置为 TRUE，因为开销很小，可以忽略不计，但alert日志中的信息可能会非常有用。
有关上述实例参数会如何影响检查点的更多详细信息，请参阅 Note:76713.1
每次切换日志时都会发生一次检查点。如果上一个检查点已在进行中，由日志切换引起的检查点将覆盖当前检查点。此时就需要大小合适的 redo 日志，以避免因频繁的日志切换而引起不必要的检查点。另外，增量检查点目标和日志尾之间的间隔也会受“最小在线日志文件大小的 90%”设置所限制。这样可确保在大多数情况下，日志切换不必等待检查点。因此，日志文件大小应配置得足够大。一个好的办法是，最多每二十分钟切换一次日志。日志文件过小会增加检查点活动并降低性能。Oracle 建议用户将所有在线日志文件设置为同一大小，且每个线程至少拥有两个日志组。若要监视日志切换发生的速度，以及随后的检查点发生的速度，alert日志是一个很有价值的工具。
以下是通过alert日志发现日志切换过于频繁的示例：
Fri May 16 17:15:43 1997
Thread 1 advanced to log sequence 1272
Current log# 3 seq# 1272 mem# 0: /prod1/oradata/logs/redologs03.log
Thread 1 advanced to log sequence 1273
Current log# 1 seq# 1273 mem# 0: /prod1/oradata/logs/redologs01.log
Fri May 16 17:17:25 1997
Thread 1 advanced to log sequence 1274
Current log# 2 seq# 1274 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 advanced to log sequence 1275
Current log# 3 seq# 1275 mem# 0: /prod1/oradata/logs/redologs03.log
Fri May 16 17:20:51 1997
Thread 1 advanced to log sequence 1276
Current log# 1 seq# 1276 mem# 0: /prod1/oradata/logs/redologs01.log
如果 redo 日志每 3 分钟切换一次，您就会察觉到性能降低。这表明 redo 日志不够大，不能有效地处理该事务负载。
有关如何估计 redo 日志文件的适当大小的详细信息，请参阅 Note:1038851.6 。有关如何重新调节在线 redo 日志文件大小的示例，请参阅 Note:1035935.6 。
5. 了解检查点错误消息（“Cannot allocate new log”和“Checkpoint not complete”）
有时，您可以在 alert.log 文件中看到以下相应消息：Thread 1 advanced to log sequence 248
Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 cannot allocate new log, sequence 249
Checkpoint not complete
此信息表明 Oracle 希望重新使用某个 redo 日志文件，但当前的检查点位置仍位于该日志中。在这种情况下，Oracle 必须等到检查点位置通过该日志。由于增量检查点目标相对于当前日志尾的滞后绝不会超过最小日志文件大小的 90% 以上，因此，如果 DBWR 写入速度过慢，或者在日志全满之前发生日志切换，或者日志文件过小，就会遇到这种情况。在数据库等待检查点时，redo 生成过程会停止，直到完成日志切换。
在 Oracle8i 中，初始化参数 FAST_START_IO_TARGET 会使增量检查点自动调整其目标，从而使恢复所需的数据块数量不多于 FAST_START_IO_TARGET 设置的值。自 Oracle 9i 开始，已弃用此参数，取而代之的是参数 FAST_START_MTTR_TARGET。
您可以每 15 分钟左右收集一次 Statspack 快照，这些快照报告将收集有关在该时间段已开始的检查点数量、已完成的检查点数量及检查点发生时写入的数据库缓冲数量的有用信息。此外，还包含关于 redo 活动的统计信息。通过收集和比较这些快照报告，您可以完整地了解不同时期的检查点性能。Statspack 报告中另一个值得关注的内容是等待事件，下面的等待事件明确指出了 redo 日志吞吐量和检查点的问题：
log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch/archive
log file switch (clearing log file)
log file switch completion
log switch/archive
log file sync
如果上述等待事件中的一个或多个频繁地出现，且相关数值较大，那您就需要采取行动了，例如添加更多的在线 redo 日志文件，或增加其大小和/或修改检查点参数。
参考
NOTE:76713.1 - 8i Parameters that Influence CheckpointsNOTE:1038851.6 - How to Estimate Size of Redo Logs
11G中FAST_START_MTTR_TARGET参数
SQL> select * from v$version;BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> col name for a20
SQL> col value for a30
SQL> select name,value from v$spparameter where name like 'fast_start_mt%';
NAME VALUE
-------------------- ------------------------------
fast_start_mttr_targ
et
alert.log中信息
Successful open of redo thread 2
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Jul 13 13:27:28 2013
SMON: enabling cache recovery
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
概念说明
一、关于FAST_START_MTTR_TARGET参数
是一个加快实例恢复的参数，我们可以根据服务级别来定义一个合理的、可接受的值，该值的单位为秒。比如设定为60s，即1分钟。
假定该值处于合理的情况之下，则一旦实例崩溃，在60s以内实例应当能够被恢复。合理即是该值不能太大，也不能太小。太大则实例恢
复所需的时间较长，太小则导致大量数据的及时写入，增加了系统的I/O。
影响实例恢复时间长短的主要因素即是从最近检查点位置到联机重做日志尾部之间的距离。距离越长则所需要的cache recovery 和undo、
redo的时间越长。所以如何有效的缩短最近检查点位置与联机重做日志尾部之间的距离，这正是FAST_START_MTTR_TARGET的目的。
关于检查点的触发条件有很多，比如日志切换、数据库shutdown、开始结束备份表空间等。检查点的分类也很多，比如完全检查点、部
分检查点、增量检查点等。
FAST_START_MTTR_TARGET的值实际上也是触发检查点的一个触发条件。当内存中产生的dirty buffer所需的恢复时间(estimated_mttr)
如果到达FAST_START_MTTR_TARGET的指定时间，则检查点进程被触发。检查点进程一旦被触发，将通知DBWn进程将按检查点队列顺序将脏数
据写入到数据文件，从而缩短了最后检查点位置与联机重做日志间的距离，减少了实例恢复所需的时间。
二、两个重要的视图
v$instacne_recovery
v$mttr_target_advice
三、设定FAST_START_MTTR_TARGET
根据实际需要来设定FAST_START_MTTR_TARGET的值，这个值的设定需要考虑到可接受的实例的恢复时间、可承受的I/O吞吐量等等。
假定我们将该值设定为
SQL> alter system set fast_start_mttr_target = 30 ;
在事务频繁的时间段来考察视图v$instacne_recovery提供的值
一、关于FAST_START_MTTR_TARGET参数
是一个加快实例恢复的参数，我们可以根据服务级别来定义一个合理的、可接受的值，该值的单位为秒。比如设定为60s，即1分钟。
假定该值处于合理的情况之下，则一旦实例崩溃，在60s以内实例应当能够被恢复。合理即是该值不能太大，也不能太小。太大则实例恢
复所需的时间较长，太小则导致大量数据的及时写入，增加了系统的I/O。
影响实例恢复时间长短的主要因素即是从最近检查点位置到联机重做日志尾部之间的距离。距离越长则所需要的cache recovery 和undo、
redo的时间越长。所以如何有效的缩短最近检查点位置与联机重做日志尾部之间的距离，这正是FAST_START_MTTR_TARGET的目的。
关于检查点的触发条件有很多，比如日志切换、数据库shutdown、开始结束备份表空间等。检查点的分类也很多，比如完全检查点、部
分检查点、增量检查点等。
FAST_START_MTTR_TARGET的值实际上也是触发检查点的一个触发条件。当内存中产生的dirty buffer所需的恢复时间(estimated_mttr)
如果到达FAST_START_MTTR_TARGET的指定时间，则检查点进程被触发。检查点进程一旦被触发，将通知DBWn进程将按检查点队列顺序将脏数
据写入到数据文件，从而缩短了最后检查点位置与联机重做日志间的距离，减少了实例恢复所需的时间。
关于实例的恢复以及检查的具体分类描述等，请参考：
Oracle实例和Oracle数据库(Oracle体系结构)
二、FAST_START_MTTR_TARGET = 0的质疑
很多文章描述了FAST_START_MTTR_TARGET = 0，即为未设置，表示启用自动检查点功能，下面是来自Oracle的官方文档中的一段，
原文的链接为：Fast-Start Fault Recovery
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.
从第一段中粗体标记的描述来看，当设定一个大于0的值给FAST_START_MTTR_TARGET，则自动调整检查点功能别启用。即fast-start
checkpointing，更准确的说应该是快速启动检查点功能
再看下面的这段描述，这段来自Oracle 10g OCP workshop I 14-17 英文版教程(Edition 3.1 December 2008)
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设置为将关闭检查点自动调整功能。
三、设定FAST_START_MTTR_TARGET
根据实际需要来设定FAST_START_MTTR_TARGET的值，这个值的设定需要考虑到可接受的实例的恢复时间、可承受的I/O吞吐量等等。
假定我们将该值设定为
SQL> alter system set fast_start_mttr_target = 30 ;
在事务频繁的时间段来考察视图v$instacne_recovery提供的值
SQL> desc v$instance_recovery; --查看v$instance_recovery视图的结构
Name Null? Type
----------------------------------------- -------- ----------------------------
RECOVERY_ESTIMATED_IOS NUMBER
ACTUAL_REDO_BLKS NUMBER
TARGET_REDO_BLKS NUMBER
LOG_FILE_SIZE_REDO_BLKS NUMBER
LOG_CHKPT_TIMEOUT_REDO_BLKS NUMBER
LOG_CHKPT_INTERVAL_REDO_BLKS NUMBER
FAST_START_IO_TARGET_REDO_BLKS NUMBER
TARGET_MTTR NUMBER
ESTIMATED_MTTR NUMBER
CKPT_BLOCK_WRITES NUMBER
OPTIMAL_LOGFILE_SIZE NUMBER
ESTD_CLUSTER_AVAILABLE_TIME NUMBER
WRITES_MTTR NUMBER
WRITES_LOGFILE_SIZE NUMBER
WRITES_LOG_CHECKPOINT_SETTINGS NUMBER
WRITES_OTHER_SETTINGS NUMBER
WRITES_AUTOTUNE NUMBER
WRITES_FULL_THREAD_CKPT NUMBER
两个字段：
TARGET_MTTR -->参照fast_start_mttr_target参数中设定的值计算出来的一个值
ESTIMATED_MTTR -->系统根据dirty buffer 中计算出来的值
可能出现的情况
1.TARGET_MTTR > ESTIMATED_MTTR --大量的事务将导致这种情况的出现
2.TARGET_MTTR < ESTIMATED_MTTR --数据库刚刚启动时，几乎没有事务时会出现这种情况
SQL> select recovery_estimated_ios,actual_redo_blks ,target_redo_blks ,
2 target_mttr,estimated_mttr
3 from v$instance_recovery;
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR
---------------------- ---------------- ---------------- ----------- --------------
55 147 707 33 27
可以在负载的情况下根据TARGET_MTTR来值通过v$mttr_target_advice调整该参数
四、启用MTTR Advisory
需要设置两个参数
STATISTICS_LEVEL -->置为typical 或者all
FAST_START_MTTR_TARGET -->置为非零值
SQL> show parameter mttr; --目标mttr_time设定为30 s
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 30
SQL> select target_mttr,estimated_mttr from v$instance_recovery; --系统计算出来的mttr为33
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
33 27
SQL> select mttr_target_for_estimate tar_est,dirty_limit,estd_cache_writes est_c_w,
2 estd_cache_write_factor est_c_w_f,estd_total_writes est_t_w,estd_total_write_factor est_t_w_f
3 from v$mttr_target_advice;
TAR_EST DIRTY_LIMIT EST_C_W EST_C_W_F EST_T_W EST_T_W_F
---------- ----------- ---------- ---------- ---------- ----------
60 5028 3762 .7376 3762 .7376
34 1000 5100 1 5100 1
68 6248 3762 .7376 3762 .7376
52 3808 3762 .7376 3762 .7376
45 2735 3845 .7539 3845 .7539
--mttr_target_for_estimate有一个值为的最接近设定的目标时间30，以及由系统计算出的的target_mttr时间33
--同时也给出了几组不同的mttr_target值及dirty_limit,cache_write,io 等来供DBA来选择设定合适的mttr
五、两个重要的视图
v$instacne_recovery
v$mttr_target_advice
由于Oracle中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步数据库，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：
1、完全检查点
在Oracle8i之前，数据库的发生的检查点都是完全检查点。完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，同时将最新的checkpoint scn更新到所有的数据文件头部及控制文件。保证数据库的处于一致的状态。需要注意的是，完 全检查点产生的时候，CKPT并不是把当前完全检查点发生那一时刻的SCN更新到控制文件和数据文件头，而是将这个触发检查点时刻DBWn当前刚写完 dirty buffer对应的SCN更新到控制文件和数据文件头，也就是说，更新控制文件和数据文件头的SCN是滞后于完全检查点的发生那一时刻的SCN的，这个从恢复的原理也很容易理解，因为检查点发生的时候要写入dirty buffer还没有写入，自然不能立即更新成当前的SCN了。需 要注意的是, 在oracle8之前，由于没有chekpoint queue，也没有增量检查点的概念，发生完全检查点时，DBWn会以一种无序的方式将所有的 dirty buffer写出到数据文件，这个时候Oracle会冻结所有DML操作等候所有dirty buffer被写出，巨大的IO往往会影响到数据库的性 能。后来随着Oracle数据库的发展和buffer cache的不断增大，oracle 意识到这个单一的Full checkpoint机制已经不能满足需要，所以在Oracle 8i后提出增量检查点的概念，建立了checkpoint queue ，让dirty buffer header根据首次变化时候的顺序(LRBA)排列在queue里面。 这样DBWn只要顺着queue的顺序写，而其他进程不必等候dbwr的写完成就可以继续。 因此增量检查点的概念就由此产生了。
完全检查点在8i之后只有在下列两种情况下才会发生：
DBA手工执行alter system checkpoint的命令；
数据库正常shutdown (immediate,transcational,normal)。
2、增量检查点
说白了，就是
CKPT每3秒一次的检查DBWn写进度并在控制文件中记录检查点位置(checkpoint position)和更新heartbeat信息
以及
CKPT定期触发DBWn去写checkpoint queue中的脏数据
这两项操作合一起被称为增量检查点。 -->可能这块描述的过于笼统，大家继续往下看:-)
我们都知道被修改过的数据块，在oracle中都被统称为脏数据块(dirty buffer)。所有的脏块被一个链表串起来,称做检查点队列(checkpoint queue)。在buffer cache中,每一个块都有一个buffer header简称BH, 在BH中有一个ckptq项, 此项目中记录了指向检查点队列上一个块和下一个块的指针。 如果某一个块不在检查点队列中,他的ckptq项为空.通过ckptq项oracle将所有的脏块串成了一个双向链表。这个双向链表就是检查点队列了。
Oracle 从8i开始引入了检查点队列(checkpoint queue)的概念，用于记录数据库里面当前所有的dirty buffer的信息，这些dirty buffer的信息按被修改的时间先后存放在checkpoint queue里面(当块首次被更改时，块会立即被加进检查点队列)，所涉及的条目主要包含RBA (Redo Block Address，重做日志里面用于标识事务期间数据块在重做日志里面发生更改的编号)和数据块的数据文件号和块号。
不 论数据块(buffer)更改几次，它在checkpoint queue里面的位置始终保持不变，checkpoint queue也只会记录它最早的RBA(这个最早的RBA其实就是Low RBA，也就是数据块第一次被修改时所对应的RBA)，从而保证最早更改的数据块能够尽快从内存写入数据文件。DBWR每到一定的时机，就会被触发 (DBWn并不是只有当检查点发生的时候才写，它大约有10几种条件触发写操作)，沿着检查点队列的顺序刷新脏块，同时CKPT进程，会监控着检查点队列 的长度，当检查点队列的长度达到一定限制时(具体有几个参数来确定checkpoing queue的长度，下面会提到比如log_checkpoint_timeout,fast_start_mttr_target等)，CKPT会通知 DBWR写脏块。CKPT会根据几个参数的设置和I/O的速度以及繁忙程度，计算出来一个Target rba(目标rba)，DBWn会沿着检查点队列，按照dirty buffer的Low RBA顺序将所有Target rba之前对应的脏块从内存写入数据磁盘文件。当CKPT通知完DBWn Target rba后，CKPT的任务就结束了。他并不会等待DBWn写完所有的Target rba之前的脏块。因此这里CKPT只是起到了一个通知DBWn进程写入的作用。
当完全检查点发 生的时候，Oracle一方面通知DBWn进行下一批写操作，另一方面是将这个触发检查点时刻DBWn当前刚写完dirty buffer对应的SCN写入数据文件头和控制文件，这个SCN就是checkpoint scn。但Oracle考虑到检查点SCN的间隔还是太大了，因为检查点的触发条件有限，周期可能比较长，有些情况下比如检查点需要5分钟左右才触发，那 这个时候系统crash再重新启动就意味着很可能系统需要5分钟左右才能启动。于是Oracle采用了一个heartbeat的概念，以3秒的频率将 DBWn写的进度反应到控制文件中，这样系统crash重新启动的时候将从更近的一个时间点开始恢复。Oracle这么做的目的就是要缩短崩溃恢复时间！ 因此CKPT另外一个任务就是每3秒，检测一次DBWn的写进度。DBWn 是沿着检查点队列写脏块，由于这里有一个顺序的关系，所以DBWn的写的进度就是可衡量的，写到哪个buffer的时候该buffer的首次变化时候的 scn(对应了LRba)就是当前所有数据文件block的上面最新scn，但是由于无法适时的将DBWn的进度记录下来，所以Oracle选择了一些策 略。 其中就包括CKPT进程的检查点位置更新和心跳，所以说CKPT每3秒钟查看一下DBWn沿检查点队列写到了哪里,并且将这个位置设置为检查点位置 (checkpont position)。也就是说检查点位置之前的块，都是已被DBWn刷新到磁盘上的块。因此我们可以理解为，CKPT进程每3秒会根据DBWn写的进度设置并记录一个检查点位置，也就是说这个检查点位置就是由DBWn的在往Target RBA写过程中的进度决定的(如果没有dirty buffer产生，那么就不会更新检查点位置信息)。因 此CKPT每3秒会将检查点位置对应的数据块的rba (low cache rba-表示Instance Recovery时开始恢复的日志条目)更新和记录到控制文件的CHECKPOINT PROGRESS RECORDS区域，当然同时被记录进控制文件的还有heartbeat等其他信息。DBWn将检查点队列里面的dirty buffer写入到数据文件后，检查点的位置也要相应地往后移。
检 查点位置(checkpoint position)实际上就可以直接理解为是一个rba，他指向着重做日志文件中的某条重做记录。在此检查点位置前的重做记录，其对应的buffer cache中的dirty buffer已经被写进了数据文件，在此位置后的重做记录，所对应数据脏块有可能还在内存中。如果发生了实例崩溃，只需要在日志文件中找到检查点位置 (low cache rba)，从此处开始应用所有的重做日志文件，就完成了前滚操作。实例崩溃后，再次启动数据库，oracle会到控制文件中读取low cache rba，这就是检查点位置。从此处开始应用重做日志，应用到on disk rba的位置。 on disk rba是磁盘中重做日志文件的最后一条重做记录的rba。 如 果某条重做记录的rba高于on disk rba，那说明此重做记录还没有被写进日志文件中，崩溃发生时，他是不可能被恢复的。on disk rba是oracle前滚操作的终点。比这个更高的rba，都应该还驻留在log buffer中。还没有被LGWR写入日志文件。所以是不能被用于恢复的。
在DBWn写dirty buffer这个检查点过程中，Oracle也可以继续产生dirty buffer，DBWn也不是一次要把所有dirty buffer全部写到磁盘(不同于完全检查点的地方)，这样就提高了检查点的效率，使得数据库要做恢复的时候从这个最新位置开始做恢复，而不是从数据文件 中的checkpoint scn(上一个完全检查点位置) 开始做恢复，这样将缩短恢复时间。
Oracle 11g 的 Concept里面提到：An incremental checkpoint is a type of thread checkpoint partly intended to avoid writing large numbers of blocks at online redo log switches. DBWn checks at least every three seconds to determine whether it has work to do. When DBWn writes dirty buffers, it advances the checkpoint position, causing CKPT to write the checkpoint position to the control file, but not to the data file headers.
因此我们需要注意的是： 增量检查点并不会去更新数据文件头，以及控制文件中数据库SCN以及数据文件条目的SCN信息，而只是每3秒由CKPT进程去更新控制文件中的low cache rba信息，也就是检查点的位置。
检查点位置发生变更后, Oracle主要通过4个参数和1个机制来控制检查点位置和最后的重做日志条目之间的距离(检查点队列的长度)。
fast_start_io_target (Oracle 9i以后已经废弃)
该 参数用于表示数据库发生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。
fast_start_mttr_target
我 们从上面可以看到fast_start_io_target来估算检查点位置比较麻烦。Oracle为了简化这个概念，从9i开始引入了 fast_start_mttr_target这么一个参数，用于表示数据库发生Instance Recovery的时间，以秒为单位。这个参数我们从字面上也比较好理解，其中的mttr是mean time to recovery的简写，如上例中的情况我们可以将fast_start_mttr_target设置为600。注意当设置了 fast_start_mttr_target后, fast_start_io_target这个参数将不再生效，从9i后 fast_start_io_target这个参数被Oracle废除了。
log_checkpoint_timeout
该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔，以秒为单位，默认情况下是1800秒。 相 比fast_start_mttr_target，它也是时间，但它的时间值表示完成恢复操作所需要的时间，即从最后的检查点位置开始，应用所有日志直到 日志末尾所需要的时间。而本参数log_checkpoint_timeout表示从最后的检查点位置开始,到日志末尾经过的时间。
log_checkpoint_interval
该参数是表示检查点位置和重做日志末尾的重做日志块的数量，以OS块表示。
90% OF SMALLEST REDO LOG
除了以上4个初始化参数外，Oracle内部事实上还将重做日志文件末尾前面90%的位置设为检查点位置。在每个重做日志中，这么几个参数指定的位置可能不尽相同，Oracle将离日志文件末尾最近的那个位置确认为检查点位置。
在Oracle 9i后,对检查点频率,建议只设置fast_start_mttr_target。根据需要,也可以通过设置 log_checkpoint_timeout,设置一个脏块保持脏状态的最大时间，而其他两个参数 fast_start_io_target,log_checkpoint_interval建议不再使用。
什么是增量检查点？
最近对增量检查点和全局检查点有些疑惑，查看了很多的资料感觉都写得非常复杂不容易理解。下面贴出一些自己的心得，如果有错误的地方希望得到指正。
1，什么是检查点
检查点是数据库事件，它是指当前数据库dbwr进程将脏块从db buffer写到数据文件的进度，减少实例崩溃后，实例恢复的时间，是实例恢复的起点。
2，检查点的分类
全局检查点：通常是dba手动生成 alter system checkpoint 或者正常关闭数据库的时候会自动产生。
增量检查点：这个比较复杂可以从dbwr写的条件说起
dbwr写的条件
1,检查点发生的时候
2，脏块达到三分之一
3，没有空闲的块
4，timeout occurs
5，rac ping request is made
6，表空间的脱机，只读，热备份
7，表的drop和truncate
一， 从上面可以看出，dbwr写的时候并不只是检查点发生的时候，也就是说即使检查点没有发生dbwr也可能在写脏块。 那么数据库如果只是记录了全局检查点，实例崩溃后，很多dbwr已经写到数据文件中的脏块也会被应用日志。增加了实例恢复的时间。
二，通过增量检查点 ：oracle在db buffer中有个检查点队列也叫脏队列，ckpt进程会每三秒去读去dbwr写的进展，并把这个点记录到控制文件中，但是不会记录到数据文件头，也就是说它记录的是dbwr实时的写入情况。这样当实例崩溃后，需要进行实例恢复，数据库就可以从控制文件中读取这个增量检查点作为实例恢复的起点，减少实例恢复的时间。
两个概念 ：
1， CKPT每3秒一次将检查点位置记录进控制文件,当然同时被记录进控制文件的 还有'心跳'等其他信息.CKPT每3秒一次的工作和CKPT定期触发DBWR,这两项操作合一起被称为--增量检查
2，增量检查点并不会去更新数据文件头，以及控制文件中数据库SCN以及数据文件条目的SCN信息，而只是每3秒由CKPT进程去更新控制文件中的low cache rba信息，也就是检查点的位置。
被修改过的块，在oracle中都被统称为脏块.所有的脏块被一个链表串起来,称做检查点队列.在buffer
cache中,每一个块都有一个buffer header 简称BH,在BH中有一个ckptq项,此项目中记录了指向检查点队
列上一个块和下一个块的指针.如果某一个块不在检查点队列中,他的ckptq项为空.通过ckptq项oracle将
所有的脏块串成了一个双向链表.这个双向链表就是检查点队列了.
1,只有脏块才会在检查点队列中,非脏块的ckptq为空.
2,当块首次被更改时,块会立即被加进检查点队列.如果检查点队列中的脏块再次被修改,并不会改变其在
检查点队列中的位置.
3,检查点队列中脏块的排列顺序:根据第2点,所有脏块按照首次被更改的时间的顺序排列.更准确点说:按
照块的lrba排列.
**什么是rba?lrba?hrba?
rba就是重做块地址,比如说,用户发出了一条update命令,更新了块A,块A现在变成了脏块,oracle会为他
生成一条重做记录.这条重做记录在重做日志文件中的位置就是rba(redo block address).过了一会儿,假
如:块A依然还是脏块,此时.用户又发出一条更新块A的命令,这又会生成一条重做记录.第一条更新命令对
应的重做记录的rba被称为块A的lrba(low rba),第二条更新命令对应的rba,被称为hrba(high rba).
其实,按照lrba来排列,就是按照块首次被修改的顺序来排列.
下面说说DBWR写脏块的方式,有了检查点队列之后,脏块按照首次变脏的时间顺序排列,DBWR每到一定的
时机,就会被触发,沿着检查点队列的顺序刷新脏块,具体在oracle中有几个参数用来确定检查点队列的长
度.另有一个CKPT进程,会监控着检查点队列的长度,当检查点队列的长度达到一定限制时,CKPT会通知DBWR
写脏块.CKPT会根据参数的设置和I/O的速度以及繁忙程度,计算出来一个Target rba(目标rba),DBWR会沿
着检查点队列,将所有Target rba之前的脏块刷新到磁盘.当CKPT通知完DBWR Target rba后,CKPT的任务就
结束了.他并不会等待DBWR写完所有的Target rba之前的脏块.通知DBWR写脏块,这是CKPT的任务之一,CKPT
另有一个任务,就是每3秒,检测一次DBWR的写进度.检查点队列最前面的块被称为检查点位置.DBWR是沿着
检查点队列写脏块的,CKPT每3秒钟查看一下DBWR沿检查点队列写到了哪里,并且将这个位置设置为检查点
位置.也就是说检查点位置之前的块,都是已被DBWR刷新到磁盘上的块.这个3秒一次检查DBWR进度的工作,
也是CKPT的一个重要的任务.CKPT每3秒一次将检查点位置记录进控制文件,当然同时被记录进控制文件的
还有'心跳'等其他信息.CKPT每3秒一次的工作和CKPT定期触发DBWR,这两项操作合一起被称为--增量检查
点.
画思维导图太费事，直接手打。
磁盘块在buffer中对应的buffers被修改后称为脏块，修改为脏块时不同步写入数据文件，而同步写到log buffer。
当buffer里有太多脏块时或其他原因，会有多种方式触发DBWR把脏块写到数据文件，腾出buffer空间，每种方式可能按不同的优先顺序写脏块，也就是按不同的链来写，其中一种是按lrba的顺序写。
先静态的解释一些名词，再讨论增量检查点的过程。
RBA（redo buffer address）脏块指向的redo buffer内存物理地址，lrba是指buffers第一次被修改时的rba，也就是这个buffers成为脏块时的rba，以后再脏多少次，他成为脏块的时候间不变，即lrba不会变。脏块最近一次被脏的rba称为hrba，两个rba之间的rba没有特定名称，他们这个脏块被事务修改的全部重做日志记录。所有脏块都有lrba和hrba，如果只脏过一次，两个rba相同。
CKPTQ。将所有脏块的lrba链起来就是CKPTQ检查点队列。（不知道buffer真的有这个队列的独立物理结构，还是所有脏块lrba信息在逻辑上向下指，在概念上形成CKPTQ。）
CKPT有多种词性，指一个动作，如进行CKPT，这次检查点；指一个进程，如CKPT进程；指逻辑上的一个时间点，检查点位置。
LRBA。每个脏块里有个LRBA信息，控制文件中也有个LRBA，准确的讲叫 low cache rba，他是ckpt进程从某一个脏块里读取过来的。
On disk RBA。先记着他指向log file里最新的（最后的）一条重做日志条目，他也是ckpt进程从某一个脏块里读取过来的。
增量检查点工作过程，和在实例恢复中的作用
只是串行化的图出重做日志条目，不必区分这些条目是否是current logfile。
一个脏块对应一个事务，但不一定对应一个重做日志条目，因为脏块脏一次产生一条重做日志条目。
1.CKPT进程发现CKPTQ太长（多长算长，oracle里有些参数可以控制），打算通知DBWR让他刷出一些脏块，缩短CKPTQ，从low cache rba到t
>
>
<<<<<<<<<<
>
>
<<<<<<<<<<<<<
<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<
>
<<<<<<<<
>
>
>
>
<<<<<<<<<<
<<<<<<<<<
<<<<<<<<<<
>
<<<<<<<<<<<<
>
>
>
<<<<<<<<<<
<<<<<<<<<<
>
<<<<<<<<<<<<<<<<<<<<
>
>
<<<<<<<<<<<<<
>
<<<<<<<<<<
>
<<<<<<<<<<<<<<<<
>
>
>
>
> <
>
>
>
>
>
>
>
>
>
>
>
>
>>
>>>>>>>>
<><><<<<>>>>><<<>>><<>><><><><><>
>
>>>>>>>>
