共計 2802 個字符，預計需要花費 8 分鐘才能閱讀完成。

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

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

  概述

一大早運維團隊就來找事，說系統又有點卡了，然后發現了一個比較少見的等待事件 –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 等待。

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