enq: KO - fast object checkpoint 等待事件與 direct path read - 2

   查詢發現等待事件 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  等待事件發生。 如果發生這種等待事件，一個簡單的查詢可能也會變得非常慢。