概述

一大早運維團隊就來找事，說系統(tǒng)又有點卡了，然后發(fā)現(xiàn)了一個比較少見的等待事件--kfk: async disk IO，趁著這次排查的過程也簡單說下這個等待事件吧!

[[275243]]

1、查看TOP N等待事件

SELECT inst_id,EVENT, SUM(DECODE(WAIT_TIME, 0, 0, 1)) "Prev", SUM(DECODE(WAIT_TIME, 0, 1, 0)) "Curr", COUNT(*) "Tot" ,  
sum(SECONDS_IN_WAIT) SECONDS_IN_WAIT 
FROM GV$SESSION_WAIT 
WHERE event NOT 
IN ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client','gcs remote message') 
AND event NOT LIKE '%idle%' 
AND event NOT LIKE '%Idle%' 
AND event NOT LIKE '%Streams AQ%' 
GROUP BY inst_id,EVENT 
ORDER BY 1,5 desc; 
--class slave wait 

可以發(fā)現(xiàn)排在前面的是kfk: async disk IO等待事件。

2、根據(jù)等待事件查會話

SELECT /*+rule */ sid, s.serial#, spid, event, sql_id, seconds_in_wait ws, row_wait_obj# obj, 
s.username, s.machine, BLOCKING_INSTANCE||'.'||blocking_session b_sess  
FROM v$session s, v$process p  
WHERE event='&event_name' AND s.paddr = p.addr order by 6; 

3、查詢某個會話詳情

SELECT /*+rule */ sid, s.serial#, spid, event, sql_id, seconds_in_wait ws, row_wait_obj# obj, 
s.username, s.machine, BLOCKING_INSTANCE||'.'||blocking_session b_sess  
FROM v$session s, v$process p  
WHERE event='&event_name' AND s.paddr = p.addr order by 6; 

顯示在備份..

4、檢查服務器是否在備份?

查看備份日志發(fā)現(xiàn)確實是正在做0級全備。

5、查看kfk: async disk IO

select name,parameter1,parameter2,parameter3,wait_class from v$event_name where name='kfk: async disk IO'; 

6、關于kfk: async disk IO

kfk: async disk IO等待事件是ASM下異步的System I/O等待事件，kfk內(nèi)核層面在disk_asynch_io=true時被激活。當rbal或其他ASM相關后臺進程在維護ASM磁盤組時可能進入kfk: async disk IO等待。

先確定一點，kfk: async disk IO是11G后ASM下直接路徑操作和ASM維護操作時會遇到的一個等待事件。

先來看大牛的描述吧：

異步IO的兩個函數(shù)：io_submit和io_getevents，Oracle是先調(diào)用io_submit發(fā)起異步IO，然后調(diào)用io_getevents查看IO狀態(tài)。

從圖中可以看到，這位大牛認為，io_submit階段，等待是kfk: async disk IO， 從io_getevents到IO完成，是direct path read。

再來看看緊接著的下幅圖：

在這幅圖中，這位大師打開10046，并同時用Truss、Strace類的工具跟蹤進程的執(zhí)行，跟蹤結果中，先有io_submit調(diào)用，馬上就是向10046跟蹤文件中寫kfk: async disk IO等待。在io_getevents調(diào)用后，又緊接著是向10046跟蹤文件中寫direct path read等待事件。據(jù)此，此大師得出結論，io_submit期間，等待事件是kfk: async disk IO，io_getevents則對應direct path read。

但實際情況kfk: async disk IO并不如此簡單，因為如果是io_submit對應kfk: async disk IO，io_getevents對應direct path read。我們都知道，間路徑IO，db file scattered read等待事件時，異步IO的完成，也是先io_submit發(fā)出IO，再在后面使用io_getevents查看IO狀態(tài)。和直接路徑一樣的，為什么間接路徑時，只有db file scattered read等待事件，并不伴隨有kfk: async disk IO等待事件呢。

顯然，是直接路徑和間接路徑的區(qū)別，產(chǎn)生了kfk: async disk IO等待。他們的區(qū)別在哪里呢，看下面這幅圖

這幅圖是直接路徑下的情況，由DTrace跟蹤得到，比Truss、Strace結果更豐富、準確。

Oracle在發(fā)出異步IO指令后，會去做一些其他的事情，并不等待IO完成。異步IO嗎，并不需要發(fā)出IO指令后，就一直等著IO完成。

在進行了一些操作后，Oracle調(diào)用函數(shù)，以0秒的超時查看IO的完成狀態(tài)。

0秒的超時，就是不會有任何停留，僅僅調(diào)用函數(shù)查看IO狀態(tài)，如IO已完成，則進入IO完成流程。

如IO沒有完成，會再進行一些其他操作，然后再次調(diào)用函數(shù)，以600秒超時，查看IO狀態(tài)。也就是停留最多600秒，等待IO完成。如果IO完成，進入IO完成流程。

再來看等待事件，從發(fā)出IO指令，到0秒超時，等待事件是kfk: async disk IO。如果0秒超時IO沒有完成，其后直到IO完成的等待事件是direct path read。

間接路徑時，所有IO，都是600秒超時，沒有0秒超時這一塊，所以，間接路徑只有db file scattered read等待，而沒有kfk: async disk IO等待。