关于Oracle数据库Kfk: Async Disk IO等待事件深度解析

一大早运维团队就来找事，说系统又有点卡了，然后发现了一个比较少见的等待事件--kfk: async disk IO，趁着这次排查的过程也简单说下这个等待事件吧!

概述

一大早运维团队就来找事，说系统又有点卡了，然后发现了一个比较少见的等待事件--kfk: async disk IO，趁着这次排查的过程也简单说下这个等待事件吧!

[[275243]]

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_WAIT
FROMGV$SESSION_WAIT
WHEREeventNOT
IN('smontimer','pmontimer','rdbmsipcmessage','SQL*Netmessagefromclient','gcsremotemessage')
ANDeventNOTLIKE'%idle%'
ANDeventNOTLIKE'%Idle%'
ANDeventNOTLIKE'%StreamsAQ%'
GROUPBYinst_id,EVENT
ORDERBY1,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_sess
FROMv$sessions,v$processp
WHEREevent='&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_sess
FROMv$sessions,v$processp
WHEREevent='&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等待。