ckptq检查点的工作机制

1.检查点概念--chkpoint
检查点是一个数据库事件，存在的意义在于减少崩溃恢复crash recovery时间.
检查点事件由后台进程CKPT触发，当检查点发生时，CKPT通知DBWR进程将脏数据库dirtybuffer写出到数据文件上，更新数据文件头及控制文件上的检查点信息。
数据文件头的SCN是CHECKPOINT SCN.

检查点工作原理：
在数据库中，进行数据修改时，需要先将数据读和内存中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值