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

概述

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

1、查看TOP N等待事件

SELECTinst_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_WAITFROMGV$SESSION_WAITWHEREeventNOTIN('smontimer','pmontimer','rdbmsipcmessage','SQL*Netmessagefromclient','gcsremotemessage')ANDeventNOTLIKE'%idle%'ANDeventNOTLIKE'%Idle%'ANDeventNOTLIKE'%StreamsAQ%'GROUPBYinst_id,EVENTORDERBY1,5desc;--classslavewait

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

2、根據等待事件查會話

select/*+rule*/sid,s.serial#,spid,event,sql_id,seconds_in_waitws,row_wait_obj#obj,s.username,s.machine,BLOCKING_INSTANCE||'.'||blocking_sessionb_sessFROMv$sessions,v$processpWHEREevent='&event_name'ANDs.paddr=p.addrorderby6;

3、查詢某個會話詳情

select/*+rule*/sid,s.serial#,spid,event,sql_id,seconds_in_waitws,row_wait_obj#obj,s.username,s.machine,BLOCKING_INSTANCE||'.'||blocking_sessionb_sessFROMv$sessions,v$processpWHEREevent='&event_name'ANDs.paddr=p.addrorderby6;

顯示在備份..

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

查看備份日志發現確實是正在做0級全備。

5、查看kfk: async disk IO

selectname,parameter1,parameter2,parameter3,wait_classfromv$event_namewherename='kfk:asyncdiskIO';

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等待。

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