【效能調整】等待事件(三) 常見等待事件（一）

調優就是將系統資源合理分配使用，解決各種競爭。

看看一些常見的等待事件：

版本9208

1，buffer busy waits

SQL> select a.SID,a.SEQ#,a.P1,a.P2,a.p3

2 from v$session_wait a where a.EVENT like '%busy%' and sid < 50;

SID SEQ# P1 P2 P3

---------- ---------- ---------- ---------- ----------

37 59427 20 1017536 130

46 31009 7 485691 130

SQL> select a.P1text,a.P2text,a.p3text

2 from v$session_wait a where a.EVENT like '%busy%' and sid < 50;

P1TEXT P2TEXT P3TEXT

---------------------------------------------------------------- ---------------------------------------------------------------- ----------------------------------------------------------------

file# block# id

發生buffer busy waits事件的時機就在當一個session去訪問一個在buffer cache中正在被另外一個session使用的block的時候：

當一個session需要讀入一個資料塊，而這個資料塊正被另外一個session從資料檔案中讀入buffer cache；

當一個session試圖去修改一個資料塊，而這個資料塊正在被另外一個session修改。

為了保證讀操作的session獲得一個一致性的block，也即這個塊要麼是修改後要麼是修改前的，session要修改block的頭部標示以讓其他的session等待修改全部完成。

在oracle 10g的版本1之前， buffer busy waits事件是當session等待其他session將資料塊讀入buffer cache時發生的。從10g版本1開始，這種waits更改成了read by other session事件，而buffer busy waits則是代表等待其他session對block的修改完成。並且，10g realease1還增加了一個buffer busy 的event，這個是當使用asm時，session訪問快取的metadata時發生的。

欄位引數說明：

SQL> col name on format a20

SQL> col p1 on format a20

SQL> col p2 on format a20

SQL> col p3 on format a20

SQL> select a.EVENT#,

2 a.NAME name,

3 a.PARAMETER1 p1,

4 a.PARAMETER2 p2,

5 a.PARAMETER3 p3

6 from v$event_name a

7 where a.NAME = 'buffer busy waits';

EVENT# NAME P1 P2 P3

---------- -------------------- -------------------- -------------------- --------------------

159 buffer busy waits file# block# id

SQL>

其中id在9i中是原因碼，在10g之後則是等待事件的類別。

可以通過一些sql來查詢等待的資料檔案，所在的表或者通過sid來找具體的sql。

select s.segment_name, s.partition_name

from dba_extents s

where 33547 between s.block_id and (s.block_id + s.blocks - 1)

and s.file_id = 66;

select * from v$session a where a.SID = 128;

SQL> select a.SID,a.EVENT name,a.p3

2 from v$session_wait a where a.EVENT like '%busy%' ;

SID NAME P3

---------- -------------------- ----------

115 buffer busy waits 130

204 buffer busy waits 130

134 buffer busy waits 130

326 buffer busy waits 130

344 buffer busy waits 130

290 buffer busy waits 130

6 rows selected.

等在在資料塊上，原因碼是130，意味著多個會話同時請求相同的資料塊，但這個資料塊並不在buffer cache中，需要從磁碟讀取。Oracle只允許一個會話執行實際的從磁碟讀的io，其他會話則在buffer busy waits上等待塊，執行的i/o根據具體情況在 db file sequential read或者db file scattered read事件上等待，這個事件上等待的檔案號和塊號是與其他session的buffer busy waits的檔案號塊號相對應的。

儘可能的優化sql的物理讀和邏輯讀可以減少系統中的buffer busy wait；

列舉一些原因碼：

100： blocking會話正在讀取block到cache，通常是undo block；waiting會話需要單獨訪問塊而為這些資訊建立一個新塊。

110：被阻塞的會話或者正在等待的會話需要訪問block的當前映象（讀或者寫），但blocking session正在將block讀入cache。

120： blocked session需要訪問一個block，而blocking session正在從cache中讀這個block，通常發生在查詢buffer的時候。

130：一個或者多個session需要訪問相同的block，但是這個block並在buffer中，其中一個session會執行io操作，併發出一個db file sequential read或者db file scattered read事件，而等待的session則post一個buffer busy waits事件，reason code就是130。

200： blocking session正在修改cache中的block，waiting block需要獨立訪問而去建立一個新的block。

210：當兩個程式同時去修改一個block的時候，blocked session需要在exlusive模式下block的當前版本。

220： blocking session正在修改block，而在buffer lookup過程中blocked session需要在current mode下訪問block。

230： blocking session正在修改block，而blocked session需要shared 方式訪問一個一致性的block版本。

231： blocking session正在修改block，而blocked session正在讀current 版本的block（when shared access of a coherent version of the block was wanted）

綜合來說，200以上的reason code往往和修改塊有關，而小於200的reason往往和io有關，這個可以根據資料庫中DML操作的型別結合來看，前面看到了都是130的reason code，事實上這正是一個報表系統，沒有修改操作，但是有大量的查詢操作。

如果只看系統檢視的損失值，且只看buffer busy waits並不一定就能確定是否就是有問題的，應該結合具體情況來看競爭是否是合理的。如果連續觀察v$session_wait都是大致相同的檔案號在等待，而SEQ#和block#在不停變化，那麼就要去看看是哪個檔案上發生了頻繁的等待，甚至可以確定到某一些表，然後結合v$sql來看這個表上的查詢，以及查詢消耗的資源。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16179598/viewspace-675565/，如需轉載，請註明出處，否則將追究法律責任。

【效能調整】等待事件(三) 常見等待事件（一）

相關文章