因为oracle需要随时预防可能的实例崩溃现象，所以oracle在数据库的正常运行过程中，会不断的 定位这个起点，以便在不可预期的实例崩溃中能够最有效的保护并恢复数据。同时，这个起点的选择 非常有讲究。首先，这个起点不能太靠前，太靠前意味着要处理很多的重做条目，这样会导致实例再 次启动时所进行的恢复的时间太长；其次，这个起点也不能太靠后，太靠后说明只有很少的脏数据块 没有被写入数据文件，也就是说前面已经有很多脏数据块被写入了数据文件，那也就意味着只有在 DBWR启动的很频繁的情况下，才能使得buffer cache中所残留的脏数据块的数量很少。但很明显， DBWR启动的越频繁，那么所占用的写数据文件的I/O就越严重，那么留给其他操作（比如读取buffer cache中不存在的数据块等）的I/O资源就越少。这显然也是不合理的。
从这里也可以看出，这个起点实际上说明了，在日志文件中位于这个起点之前的重做条目所对应的 在buffer cache中的脏数据块已经被写入了数据文件，从而在实例崩溃以后的恢复中不需要去考虑。 而这个起点以后的重做条目所对应的脏数据块实际还没有被写入数据文件，如果在实例崩溃以后的恢 复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。考虑到目前的内存容量 越来越大，buffer cache也越来越大，buffer cache中包含几百万个内存数据块也是很正常的现象的 前提下，如何才能最有效的来定位这个起点呢？
为了能够最佳的确定这个起点，oracle引入了名为CKPT的后台进程，通常也叫作检查点进程 （checkpoint process）。这个进程与DBWR共同合作，从而确定这个起点。同时，这个起点也有一个 专门的名字，叫做检查点位置（checkpoint position）。oracle为了在检查点的算法上更加的具有可 扩展性（也就是为了能够在巨大的buffer cache下依然有效工作），引入了检查点队列（checkpoint queue），该队列上串起来的都是脏数据块所对应的buffer header。而DBWR每次写脏数据块时，也是 从检查点队列上扫描脏数据块，并将这些脏数据块实际写入数据文件的。当写完以后，DBWR会将这些 已经写入数据文件的脏数据块从检查点队列上摘下来。这样即便是在巨大的buffer cache下工作， CKPT也能够快速的确定哪些脏数据块已经被写入了数据文件，而哪些还没有写入数据文件，显然，只 要在检查点队列上的数据块都是还没有写入数据文件的脏数据块。而且，为了更加有效的处理单实例 和多实例（RAC）环境下的表空间的检查点处理，比如将表空间设置为离线状态或者为热备份状态等， oracle还专门引入了文件队列（file queue）。文件队列的原理与检查点队列是一样的，只不过每个 数据文件会有一个文件队列，该数据文件所对应的脏数据块会被串在同一个文件队列上；同时为了能 够尽量减少实例崩溃后恢复的时间，oracle还引入了增量检查点（incremental checkpoint），从而 增加了检查点启动的次数。如果每次检查点启动的间隔时间过长的话，再加上内存很大，可能会使得 恢复的时间过长。因为前一次检查点启动以后，标识出了这个起点。然后在第二次检查点启动的过程 中，DBWR可能已经将很多脏数据块已经写入了数据文件，而假如在第二次检查点启动之前发生实例崩 溃，导致在日志文件中，所标识的起点仍然是上一次检查点启动时所标识的，导致oracle不知道这个 起点以后的很多重做条目所对应的脏数据块实际上已经写入了数据文件，从而使得oracle在实例恢复 时再次重复的处理一遍，效率低下，浪费时间。