欢迎大家来到IT世界,在知识的湖畔探索吧!
概述
一大早运维团队就来找事,说系统又有点卡了,然后发现了一个比较少见的等待事件–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
欢迎大家来到IT世界,在知识的湖畔探索吧!
可以发现排在前面的是kfk: async disk IO等待事件。
2、根据等待事件查会话
欢迎大家来到IT世界,在知识的湖畔探索吧!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
欢迎大家来到IT世界,在知识的湖畔探索吧!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等待。
后面会分享更多devops和DBA方面的内容,感兴趣的朋友可以关注下~
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/22681.html