问题： buffer cache中检查点队列与Dirty List的关系 发生实例恢复时，Oracle是根据“检查点位置”来判断恢复所需要读取的日志的起点，但这要求DBWR写buffer到磁盘时，按照buffer变“脏”的先后顺序来写。事实上，“检查点队列”也正是按此顺序排列的。但如果“脏块”是从Dirty List向磁盘写入的，这就不一定是按照“变脏的先后顺序”来写了，这对按照“检查点位置”为起点的恢复方式会有哪些影响？ 另外，是不是我理解错误，“脏块”在被写到磁盘时，是不是先要从Dirty List送进“检查点队列”中，再被写进磁盘。“检查点队列”是按照“变脏”的先后顺序排列的，所有要写的块先进入它里面排好序，再向磁盘写，顺序上就不会有什么问题了。 但如果是从Dirty List再进入“检查点队列”，是不是要有一个根据“变脏”的先后顺序排序的过程。排序是很耗时的操作，这样一来，效率岂不是有点低了吗？ 我在生产机上没办法作这方面的实验，在我自己的机器上，我更新了一个表，马上转储 Buffer cache： alter session set events 'immediate trace name buffer level 4'; 在DUMP的文件中，找到被更新的被更新的块，发现块已经在“检查点队列”中了，因为块的CKPTQ并不为NULL。 还有文档中有这样一段话：Oracle9i Database Concepts Release 2 (9.2)文档的第七章Memory Architecture中的说法： an Oracle user process searches the threshold limit of buffers without finding a free buffer, the process stops searching the LRU list and signals the DBW0 background process to write some of the dirty buffers to disk. 这里的写，应该是从LRU直接到磁盘，这时的写操作，应该也不是按照“变脏”的先后顺序。这些从LRU直接写进磁盘的块，是不是就不再进入“检查点队列”了？当写完成后，直接被buffer的状态改为“可重用”，然后挂到辅助LRU上直接被新进入buffer cache的块覆盖？