Buffer busy waits/read by other session
從本質上講，這個等待事件的產生僅說明了一個會話在等待一個Buffer（資料塊），但是導致這個現象的原因卻有很多種。常見的兩種是：
當一個會話試圖修改一個資料塊，但這個資料塊正在被另一個會話修改時。
當一個會話需要讀取一個資料塊，但這個資料塊正在被另一個會話讀取到記憶體中時。

Oracle操作的最小單位是塊（Block），即使你要修改一條記錄，也需要對這條記錄所在的這個資料塊做操作。當你對這個資料塊做修改時，其他的會話將被阻止對這個資料塊上的資料做修改（即使其他使用者修改的不是當前使用者修改的資料），但是可以以一致性的方式讀取這個資料塊（from undo）。當前的使用者修改完這個資料塊後，將會立即釋放掉加在這個資料塊上的排他鎖，這樣另一個會話就可以繼續修改它。修改操作是一個非常短暫的時間，這種加鎖的機制我們叫Latch。

當一個會話修改一個資料塊時，是按照以下步驟來完成的：
以排他的方式獲得這個資料塊（Latch）
修改這個資料塊。
釋放Latch。

Buffer busy waits等待事件常見於資料庫中存在的熱快的時候，當多個使用者頻繁地讀取或者修改同樣的資料塊時，這個等待事件就會產生。如果等待的時間很長，我們在AWR或者statspack報告中就可以看到。

這個等待事件有三個引數。檢視有幾個引數我們可以用以下SQL:
col NAME for a25
col PARAMETER1 for a15
col PARAMETER2 for a15
col PARAMETER3 for a15
select name, parameter1, parameter2, parameter3 from v$event_name where name='buffer busy waits';

NAME                      PARAMETER1      PARAMETER2      PARAMETER3
------------------------- --------------- --------------- ---------------
buffer busy waits         file#           block#          class#

如果您需要使用檔案＃和塊＃查詢段，則可以使用此查詢:
SELECT owner, segment_name, file_id, block_id starting_block_id, block_id + blocks ending_block_id, blocks
FROM dba_extents
WHERE file_id = &file_num AND ( block_id <= &block_id AND (&block_id < (block_id + blocks)) );

或者從awr的"Buffer Wait Statistics" section of AWR reports for details of block classes causing waits.

====read by other session====================
SQL> select name, parameter1, parameter2, parameter3 from v$event_name where name='read by other session';

NAME                      PARAMETER1      PARAMETER2      PARAMETER3
------------------------- --------------- --------------- ---------------
read by other session     file#           block#          class#

SELECT SID              mySID,
       blocking_session,
       p1               "FILE#",
       p2               "BLOCK#",
       p3               "class#",
       row_wait_obj#    OBJECT_ID
FROM v$session
WHERE event = 'read by other session'
   AND STATE = 'WAITING';

Buffer busy waits/read by other session

相關文章