查询发现等待事件 enq: KO - fast object checkpoint 发生的原因是：当进行TABLE FULL SCAN (全表扫描) 或并行查询整个segment时, 11g下，因_adaptive_direct_read 默认为true,  达到阀值_small_table_threshold大小的表会被认为是大表，读取数据时不会读入SGA , 而是直接路径读取(direct path read)，而direct path read 是需要将数据从磁盘读取到各session 的PGA中，因为不是读入SGA, 所以读取这些表之前需要在所有数据库节点(如果是RAC)触发object level checkpoint，将这些表被修改过的dirty buffer写入磁盘，以保证读取数据的一致性 。 

SQL> select ksppinm, ksppstvl from x$ksppi pi, x$ksppcv cv   where cv.indx = pi.indx and pi.ksppinm like '_adaptive_direct_read';
KSPPINM                  KSPPSTVL
---------               ---------------------
_adaptive_direct_read    TRUE

SQL> select ksppinm, ksppstvl from x$ksppi pi, x$ksppcv cv   where cv.indx = pi.indx and pi.ksppinm like '_small_table_threshold';

KSPPINM                  KSPPSTVL
---------               ---------------------
_small_table_threshold    15083     -- (单位为blocks，每个版本对应值貌似都不同)

  查询SQL执行计划 ：   
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('5jctyad1z1s6a',0,'all iostats last'));  
或 
select * from  table(dbms_xplan.display_awr('5jctyad1z1s6a')) ; 

发现有四个表做全表扫描，这几个表的大小(block数目)显然大于设置的_small_table_threshold阀值，所以走了direct path read, 读取数据到PGA之前需要触发object level checkpoint去将这四个表在buffer cache中的dirty buffer写入磁盘，等待checkpoint完成。相当于 ckpt 或 dbwr 阻塞了读(读入到SGA)。这时，enq: KO - fast object checkpoint  等待事件发生。 如果发生这种等待事件，一个简单的查询可能也会变得非常慢。