共计 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 的支持。