参考资料：Oracle8 Administrator's Guide, Release 8.0
Oracle8 Backup and Recovery, Release 8.0
检查点是一个数据库事件，它把修改数据从高速缓存写入磁盘，并更新控制文件和数据文件。
检查点分为三类：
1）局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。
触发命令：
svmrgrl>alter system checkpoint local;
这条命令显示的触发一个局部检查点。
2）全局检查点：所有实例（对应并行数据服务器）执行数据库所有所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。
触发命令
svrmgrl>alter system checkpoint global;
这条命令显示的触发一个全局检查点。
3）文件检查点：所有实例需要执行数据文件集的一个检查点操作，如使用热备份命令alter tablespace USERS begin backup，或表空间脱机命令alter tablespace USERS offline，将执行属于USERS表空间的所有数据文件的一个检查点操作。
检查点处理步骤：
1）获取实例状态队列：实例状态队列是在实例状态转变时获得，ORACLE获得此队列以保证检查点执行期间，数据库处于打开状态；
2）获取当前检查点信息：获取检查点记录信息的结构，此结构包括当前检查点时间、活动线程、进行检查点处理的当前线程、日志文件中恢复截止点的地址信息；
3）缓存区标识：标识所有脏缓存区，当检查点找到一个脏缓存区就将其标识为需进行刷新，标识的脏缓存区由系统进程DBWR进行写操作，将脏缓存区的内容写入数据文件；
4）脏缓存区刷新：DBWR进程将所有脏缓存区写入磁盘后，设置一标志，标识已完成脏缓存区至磁盘的写入操作。系统进程LGWR与CKPT进程将继续进行检查，直至DBWR进程结束为止；
5）更新控制文件与数据文件。
注：控制文件与数据文件头包含检查点结构信息。
在两种情况下，文件头中的检查点信息（获取当前检查点信息时）将不做更新：
1）数据文件不处于热备份方式，此时ORACLE将不知道操作系统将何时读文件头，而备份拷贝在拷贝开始时必须具有检查点SCN；
ORACLE在数据文件头中保留一个检查点的记数器，在正常操作中保证使用数据文件的当前版本，在恢复时防止恢复数据文件的错误版本；即使在热备份方式下，计数器依然是递增的；每个数据文件的检查点计数器，也保留在控制文件相对应数据文件项中。
2）检查SCN小于文件头中的检查点SCN的时候，这表明由检查点产生的改动已经写到磁盘上，在执行全局检查点的处理过程中，如果一个热备份快速检查点在更新文件头时，则可能发生此种情况。应该注意的是，ORACLE是在实际进行检查点处理的大量工作之前捕获检查SCN的，并且很有可能被一条象热备份命令alter tablespace USERS begin backup进行快速检查点处理时的命令打断。
ORACLE在进行数据文件更新之前，将验证其数据一致性，当验证完成，即更新数据文件头以反映当前检查点的情况；未经验证的数据文件与写入时出现错误的数据文件都被忽略；如果日志文件被覆盖，则这个文件可能需要进行介质恢复，在这种情况下，ORACLE系统进程DBWR将此数据文件脱机。
检 查点算法描述：
脏缓存区用一个新队列链接，称为检查点队列。对缓存区的每一个改动，都有一个与其相关的重做值。检查点队列包含脏的日志缓存区，这些缓存区按照它们在日志文件中的位置排序，即在检查点队列中，缓存区按照它们的低重做值进行排序。需要注意的是，由于缓存区是依照第一次变脏的次序链接到队列中的，所以，如果在缓存区写出之前对它有另外的改动，链接不能进行相应变更，缓存区一旦被链接到检查点队列，它就停留在此位置，直到将它被写出为止。
ORACLE系统进程DBWR在响应检查点请求时，按照这个队列的低重做值的升序写出缓存区。每个检查点请求指定一个重做值，一旦DBWR写出的缓存区重做值等于或大雨检查点的重做值，检查点处理即完成，并将记录到控制文件与数据文件。
由于检查点队列上的缓存区按照低重做值进行排序，而DBWR也按照低重做值顺序写出检查点缓存区，故可能有多个检查点请求处于活动状态，当DBWR写出缓存区时，检查位于检查点队列前端的缓存区重做值与检查点重做值的一致性，如果重做值小于检查点队列前缓存区的低重做值的所有检查点请求，即可表示处理完成。当存在未完成的活动检查点请求时，DBWR继续写出检查点缓存区。
算法特点：
1）DBWR能确切的知道为满足检查点请求需要写那些缓存区；
2）在每次进行检查点写时保证指向完成最早的（具有最低重做值的）检查点；
3）根据检查点重做值可以区别多个检查点请求，然后按照它们的顺序完成处理。
了解ORACLE检查点工作机制，对深刻理解ORACLE备份与恢复有很大的帮助，以上是本人对ORACLE检查点的一些总结，希望能对大家有所帮助。
什么是checkpoint?
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。
什么时候发生checkpoint?
我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发checkpoint。
1.当发生日志组切换的时候
2.当符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target参数设置的时候
3.当运行ALTER SYSTEM SWITCH LOGFILE的时候
4.当运行ALTER SYSTEM CHECKPOINT的时候
5.当运行alter tablespace XXX begin backup，end backup的时候
6.当运行alter tablespace ,datafile offline的时候;
增量检查点（incremental checkpoint）
oracle8以后推出了incremental checkpoint的机制，在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了 checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。
数据字典
完全检查点
select * from X$KCCRT where indx=0;ADDR
INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM
RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO
RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF
RTLFH RTLFT RTCLN RTSEQ RTENB
RTETS RTDIS RTDIT
RTLHP RTSID RTOTS-------- ---------- ---------- ---------- ----------
---------------- -------------------- ---------- ------------- ------------- -------------
---------------- ---------- ---------- ---------- ---------- ---------- ---------- -------
--- ---------------- -------------------- ---------------- -------------------- ---------
- ---------------- --------------------4084B228 0
1 1 15 720368521 06/25/2004 18:49:37
1 949 2 16 0600000000000000
2 0 3 1 3 1 949 1
05/16/2004 13:29:03 0 1389 tbdb2in1
06/12/2004 12:30:50
这里显示了上一次的完全检查点是在06/25/2004 18:49:37发生，所以我们推断06/25/2004 18:49:37发生了一次日志切换，再去操作系统上去看生产的归档，果然18：49有一个归档生产。
-rw-r----- 1 oracle oinstall 83532800 Jun 25 18:49 1_948.dbf
增量检查点
SQL> select * from X$KCCCP where indx=0;ADDR
INDX INST_ID CPTNO CPSTA CPFLG
CPDRT CPRDBCPLRBA_SEQ CPLRBA_BNO
CPLRBA_BOF
CPODR_SEQ CPODR_BNO
CPODR_BOF CPODSCPODT
CPODT_I CPHBT CPRLS
CPRLC CPMIDCPSDR_SEQ
CPSDR_BNO CPSDR_ADB-------- ---------- ----------
---------- ---------- ---------- ---------- ---------- ---------- --
-------- ---------- ---------- ---------- ---------- --------------
-- -------------------- ---------- ---------- ---------------- ----
------ ---------- ---------- ---------- ----------4084B45C
0 1 1 2 0 10762 29753
949 76847 0 949 106814
0 721554970 06/25/2004 21:05:10
529794310 529036227 1
526310932 1413781667 949
1 0
这里显示了low-rba,on-disk rba,checkpoint time等信息。
每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。
这里应该是只更新控制文件，每3秒不是更新数据文件
说 记录 checkpoint 的执行情况，这个说法，没错，但不够详细，应该说，由于增量检查点和 checkpoint queue 的原理，ckpt 进程每次只是告诉 dbwr ，写dirty buffer将要一直写到最新这个位置，仅仅是告诉 dbwr 一个 checkpoint queue 中的结束点，而 ckpt 每3秒中，在控制文件中报告一下 dbwr 最新写入的位置。这样使得，比如数据库要做恢复的时候（instance recovery）可以从这个最新位置开始做恢复，而不是从数据文件中的 checkpoint scn 开始做恢复，这样将缩短恢复时间，尤其是 instance crash 的情况下启动更快
另外要注意的是，检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的 scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去 ，也就是说，更新控制文件和数据文件头 是滞后于检查点的发生的，这个从恢复的原理也很容易理解，因为检查点发生的时候 dirty buffer还没有写入，自然不能立即更新成当前的 scn 了。
