oracle checkpoint
什么是checkpoint
在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交（commit）完成之前要先保证日志都被写入到日志文件中，而脏数据块着保存在数据缓存（buffer cache）中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。
一般所说的checkpoint是一个数据库事件（event），checkpoint事件由checkpoint进程（LGWR/CKPT进程）发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。
checkpoint的作用
checkpoint主要2个作用：
保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的；
缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。
通俗的说checkpoint就像word的自动保存一样。
checkpoint相关概念术语
RBA（Redo Byte Address）, Low RBA（LRBA）, High RBA（HRBA）
RBA就是重做日志块（redo log block）的地址，相当与数据文件中的ROWID，通过这个地址来定位重做日志块。RBA由三个部分组成：
日志文件序列号（4字节）
日志文件块编号（4字节）
重做日志记录在日志块中的起始偏移字节数（2字节）
通常使用RBA的形式有：
LRBA
数据缓存（buffer cache）中一个脏块第一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为LRBA。
HRBA
数据缓存（buffer cache）中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。
checkpoint RBA
当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpoint RBA。从上一个checkpoint RBA到当前的checkpoint RBA之间的日志所保护的buffer cache中的脏块接下来将会被写入到数据文件当中去。
Buffer checkpoint Queues （BCQ）
Oracle将所有在数据缓存中被修改的脏块按照LRBA顺序的组成一个checkpoint队列，这个队列主要记录了buffer cache第一次发生变化的时间顺序，然后有DBWn进程根据checkpoint队列顺序将脏块写入到数据文件中，这样保证了先发生变更的buffer能先被写入到数据文件中。BCQ的引入是为了支持增量checkpoint的。
Active checkpoint Queue （ACQ）
ACQ中包含了所有活动的checkpoint请求。每次有新checkpoint请求是都会在ACQ中增加一条记录，ACQ记录中包含了相应的checkpoint RBA。checkpoint完成以后相应的记录将被移出队列。
完全检查点工作过程
一个checkpoint操作可以分成三个不同的阶段：
第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpoint RBA，这个通常是当前的RBA。
第二阶段，checkpoint进程通知DBWn进程将所有checkpoint RBA之前的buffer cache里面的脏块写入磁盘。
确定脏块都被写入磁盘以后进入到第三阶段，checkpoint进程将checkpoint信息（SCN）写入/更新数据文件和控制文件中。
更新SCN的操作由CKPT进程完成，在Oracle 8.0之后CKPT进程默认是被启用的，如果CKPT进程没有启用的话那相应的操作将由LGWR进程完成。
什么时候发生normal checkpoint
下面这些操作将会触发checkpoint事件：
日志切换，通过ALTER SYSTEM SWITCH LOGFILE。
DBA发出checkpoint命令，通过ALTER SYSTEM checkpoint。
对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。
当运行ALTER TABLESPACE/DATAFILE READ ONLY的时候。
SHUTDOWN命令发出时。
特别注意：
日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。
日志切换触发的是normal checkpoint，而不是大家所说的增量checkpoint，只不过log switch checkpoint的优先级非常低，当一个log switch checkpoint发生的时候它并不会立即的通知DBWn进程去写数据文件，但是当有其它原因导致checkpoint或者是写入数据文件的RBA超过log switch checkpoint的checkpoint RBA的时候，这次的log switch checkpoint将会被标记成完成状态，同时更新控制文件和数据文件头。我们随后可以做个实验验证这个说法。
发生增量checkpoint的先决条件
恢复需求设定 （FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）
LOG_checkpoint_INTERVAL参数值
LOG_checkpoint_TIMEOUT参数值
最小的日志文件大小
buffer cache中的脏块的数量
增量checkpoint相关参数设置
log_checkpoint_interval
设定两次checkpoint之间重做日志块（重做日志块和系统数据块是一样的）数，当重做日志块数量达到设定值的时候将触发checkpoint。
log_checkpoint_timeout
设定两次checkpoint之间的间隔时间，当超时值达到时增量checkpoint将被触发。Oracle建议不用这个参数来控制，因为事务（transaction）大小不是按时间等量分布的。将此值设置成0时将禁用此项设置。
fast_start_io_target
因为log_checkpoint_interval主要看的时候重做日志块的数量，并不能反应buffer cache中脏数据块的修改，因此Oracle又引入了这个参数来实现当脏数据块达到一定数量的时候触发checkpoint，不过此参数实际上控制的是恢复时所需IO的数量。
fast_start_mttr_target
-
此参数是在9i中引入用来代替前面的三个参数的，它定义了数据块崩溃后所需要的实例恢复的时间，Oracle在实际上内在的解释成两个参数:fast_start_io_target和log_checkpoint_interval.如果这两个参数没有显式的指定,计算值将生效.。
fast_start_mttr_target可以设定的最大值是3600，即一个小时。它的最小值没有设限，但是并不是说可以设置一个任意小的值，这个值会受最小dirty buffer（最小为1000）的限制，同时还会受初始化时间以及文件打开时间的限制。
在设置此参数的时候要综合考虑系统的IO，容量以及CPU等信息，要在系统性能和故障恢复时间之间做好平衡。
将此参数设置成0时将禁用 fast-start checkpointing，这样能见效系统负载但同时会增加系统的恢复时间。
如果fast_start_io_target or log_checkpoint_interval被指定，他们会自动覆盖由fast_start_mttr_target参数计算出来的值。
在10g中，数据库能根据各种系统参数的设置值来自动调整检查点的执行频率，以获得最好的恢复时间以及系统的正常运行影响最小。通过自动checkpoint调整，Orach能在系统低IO操作的时候将脏块写入到数据文件中，因此即时DBA没有设置checkpoint相关的参数值或是设置了一个不合理的值的时候系统还是能获得一个很合理的系统恢复时间。
10g中的增量checkpoint更能体现它持续活动的特点，在10g中，增量checkpoint不是在某一个特定的条件下触发，而是由数据库根据系统参数设置自动触发。
查看系统的checkpoint动作
我们可以通过将LOG_checkpointS_TO_ALERT设置成TRUE来打开checkpoint的trace，这样就可以跟踪checkpoint的操作了。
ALTER SYSTEM SET LOG_checkpointS_TO_ALERT=TRUE;
这设置以后系统的checkpoint将会被记录alert_$SID.log文件中。
在V$DATAFILE_HEADER里面也保存了发生完全checkpoint的时候一些相关信息，包括checkpoint发生时间、对应SCN已经checkpoint的次数。
dbwr 写dirty buffer 是根据 buffer 在被首次 modify的时候的时间的顺序写出，也就是 buffer被modify 的时候会进入一个queue （checkpoint queue），dbwr 就根据queue从其中批量地写到数据文件。 由于这里有一个顺序的关系，所以 dbwr的写的进度就是可衡量的，写到哪个buffer的时候该buffer的首次变化时候的scn就是当前所有数据文件block的最新scn，但是由于无法适时的将dbwr的进度记录下来，所以oracle 选择了一些策略。 其中就包括ckpt进程的检查点和心跳。
检查点发生以后，CKPT进程检查checkpoint queue(也就是脏块链表)是否过长，如果是，则触发DBWn，将一部分脏块写入数据文件，从而缩短checkpoint queue。checkpoint 发生时，一方面通知dbwr进行下一批写操作，（dbwr 写入的时候，一次写的块数是有一个批量写的隐藏参数控制的。）另一方面，oracle 采用了一个心跳的概念，以3秒的频率将dbwr 写的进度反应到控制文件中，也就是把dbwr当前刚写完的dirty buffer对应的scn 写入数据文件头和控制文件，这就是检查点scn。
这个3秒和增量检查点不是一个概念，3秒只是在控制文件中，ckpt 进程去更新当前 dbwr写到哪里了，这个对于 ckpt 进程来说叫 heartbeat ，heartbeat是3秒一次，3秒可以看作不停的检查并记录检查点执行情况（DBWR的写进度）。
检查点发生之后数据库的数据文件、控制文件处于一致状态的含义是不需要进行 介质恢复，只表示数据文件头一致，但是并不表示数据文件内容一致，因为数据文件内容可能在没有发生检查点的其他情况下的dbwr写数据文件，这样数据文件内容就不一致，若掉电需要进行崩溃恢复。
Commit成功后，数据还会丢失吗？
对于Oracle来说，用户所做的DML操作一旦被提交，则先是在database buffer cache 中进行修改，同时在修改之前会将数据的前镜像保存在回滚段中，然后将修改之前和修改之后的数据都写入到redo log buffer中，当接收到commit命令之后，则redo log buffer开始写redo log file ，并且记录此时的scn，当redo log file 写完了之后，表示这次事务提交操作已经确认被数据库记录了，只有当redo log file 写成功了，才会给用户 Commit completed 的成功字样。而对于Database buffer cache中的dirty buffer则会等待触发DBWn才写入，但是如果此时断电，则数据已经被记录到了redo log file中，系统在重新启动的时候，会自动进行嵌滚和回滚来保证数据的一致。所以，只要是commit成功的了，数据不会丢失！
数据库发生一次DBWn，是否将所有buffer cache 中的dirty buffer 都写入，还是先将脏队列中的数据写入？
这话看起来有道理，但实际上，dbwr在写的时候又不断地在产生dirty buffer ,所以说检查点发生的时候是期望把该时间点之前的所有脏缓冲区写入数据文件。
所有的buffer，不在LRU list上就在dirty list上, dbwr写入的时候，一次写的块数是有一个批量写的隐藏参数控制的。
所以说要是 dbwr将 dirty list也好， lru list上的也好，要实现全部写入，都是一个现实系统中很难存在的现象。dirty 总是在不断的产生，dbwr总是在不断地写,增量检查点发生的时候也并不意味着一定要更新数据文件头，检查点开始的时候只表示该次检查点结束的时候要更新数据文件头的话数据文件头具有该时间点的一致性。