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

子長(zhǎng)網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)成立與2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

 概述

一大早運(yùn)維團(tuán)隊(duì)就來找事，說系統(tǒng)又有點(diǎn)卡了，然后發(fā)現(xiàn)了一個(gè)比較少見的等待事件--kfk: async disk  IO，趁著這次排查的過程也簡(jiǎn)單說下這個(gè)等待事件吧!

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

可以發(fā)現(xiàn)排在前面的是kfk: async disk IO等待事件。

2、根據(jù)等待事件查會(huì)話

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、查詢某個(gè)會(huì)話詳情

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、檢查服務(wù)器是否在備份?

查看備份日志發(fā)現(xiàn)確實(shí)是正在做0級(jí)全備。

5、查看kfk: async disk IO

select name,parameter1,parameter2,parameter3,wait_class from v$event_name where name='kfk: async disk IO';

6、關(guān)于kfk: async disk IO

kfk: async disk IO等待事件是ASM下異步的System  I/O等待事件，kfk內(nèi)核層面在disk_asynch_io=true時(shí)被激活。當(dāng)rbal或其他ASM相關(guān)后臺(tái)進(jìn)程在維護(hù)ASM磁盤組時(shí)可能進(jìn)入kfk:  async disk IO等待。

先確定一點(diǎn)，kfk: async disk IO是11G后ASM下直接路徑操作和ASM維護(hù)操作時(shí)會(huì)遇到的一個(gè)等待事件。

先來看大牛的描述吧：

異步IO的兩個(gè)函數(shù)：io_submit和io_getevents，Oracle是先調(diào)用io_submit發(fā)起異步IO，然后調(diào)用io_getevents查看IO狀態(tài)。

從圖中可以看到，這位大牛認(rèn)為，io_submit階段，等待是kfk: async disk IO， 從io_getevents到IO完成，是direct  path read。

再來看看緊接著的下幅圖：

在這幅圖中，這位大師打開10046，并同時(shí)用Truss、Strace類的工具跟蹤進(jìn)程的執(zhí)行，跟蹤結(jié)果中，先有io_submit調(diào)用，馬上就是向10046跟蹤文件中寫kfk:  async disk IO等待。在io_getevents調(diào)用后，又緊接著是向10046跟蹤文件中寫direct path  read等待事件。據(jù)此，此大師得出結(jié)論，io_submit期間，等待事件是kfk: async disk IO，io_getevents則對(duì)應(yīng)direct  path read。

但實(shí)際情況kfk: async disk IO并不如此簡(jiǎn)單，因?yàn)槿绻莍o_submit對(duì)應(yīng)kfk: async disk  IO，io_getevents對(duì)應(yīng)direct path read。我們都知道，間路徑IO，db file scattered  read等待事件時(shí)，異步IO的完成，也是先io_submit發(fā)出IO，再在后面使用io_getevents查看IO狀態(tài)。和直接路徑一樣的，為什么間接路徑時(shí)，只有db  file scattered read等待事件，并不伴隨有kfk: async disk IO等待事件呢。

顯然，是直接路徑和間接路徑的區(qū)別，產(chǎn)生了kfk: async disk IO等待。他們的區(qū)別在哪里呢，看下面這幅圖

這幅圖是直接路徑下的情況，由DTrace跟蹤得到，比Truss、Strace結(jié)果更豐富、準(zhǔn)確。

Oracle在發(fā)出異步IO指令后，會(huì)去做一些其他的事情，并不等待IO完成。異步IO嗎，并不需要發(fā)出IO指令后，就一直等著IO完成。

在進(jìn)行了一些操作后，Oracle調(diào)用函數(shù)，以0秒的超時(shí)查看IO的完成狀態(tài)。

0秒的超時(shí)，就是不會(huì)有任何停留，僅僅調(diào)用函數(shù)查看IO狀態(tài)，如IO已完成，則進(jìn)入IO完成流程。

如IO沒有完成，會(huì)再進(jìn)行一些其他操作，然后再次調(diào)用函數(shù)，以600秒超時(shí)，查看IO狀態(tài)。也就是停留最多600秒，等待IO完成。如果IO完成，進(jìn)入IO完成流程。

再來看等待事件，從發(fā)出IO指令，到0秒超時(shí)，等待事件是kfk: async disk  IO。如果0秒超時(shí)IO沒有完成，其后直到IO完成的等待事件是direct path read。

間接路徑時(shí)，所有IO，都是600秒超時(shí)，沒有0秒超時(shí)這一塊，所以，間接路徑只有db file scattered read等待，而沒有kfk: async  disk IO等待。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。