如何進行Oracle數據庫Kfk: Async Disk IO等待事件的深度解析

如何進行Oracle數據庫Kfk: Async Disk IO等待事件的深度解析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

 概述

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

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

可以發現排在前面的是kfk: async disk IO等待事件。

2、根據等待事件查會話

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、檢查服務器是否在備份?

查看備份日志發現確實是正在做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內核層面在disk_asynch_io=true時被激活。當rbal或其他ASM相關后臺進程在維護ASM磁盤組時可能進入kfk:  async disk IO等待。

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

先來看大牛的描述吧：

異步IO的兩個函數：io_submit和io_getevents，Oracle是先調用io_submit發起異步IO，然后調用io_getevents查看IO狀態。

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

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

在這幅圖中，這位大師打開10046，并同時用Truss、Strace類的工具跟蹤進程的執行，跟蹤結果中，先有io_submit調用，馬上就是向10046跟蹤文件中寫kfk:  async disk IO等待。在io_getevents調用后，又緊接著是向10046跟蹤文件中寫direct path  read等待事件。據此，此大師得出結論，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發出IO，再在后面使用io_getevents查看IO狀態。和直接路徑一樣的，為什么間接路徑時，只有db  file scattered read等待事件，并不伴隨有kfk: async disk IO等待事件呢。

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

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

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

在進行了一些操作后，Oracle調用函數，以0秒的超時查看IO的完成狀態。

0秒的超時，就是不會有任何停留，僅僅調用函數查看IO狀態，如IO已完成，則進入IO完成流程。

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

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

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

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。