wait event : read by other session

兩邊都為select所引起的” read by other session”

Buffer lock分為Shared模式和Exclusive模式，當讀取SGA中的buffer時，是屬於Shared模式，並不會引起Buffer lock，但相反若需要產生物理I/O，將buffer 載入到buffer cache時，則是發生Exclusive模式的佔用，同時也會發生db file sequential read、db file scattered read的I/O等待現象，當有另一個session也需要讀取時就會發生read by other session。

當載入SGA完成後，另一個session則進行的是邏輯I/O，若今天的情況是一開始便存在於SGA則是shared的模式，則會發生buffer busy waits。

參考: WAITEVENT: "read by other session" Reference Note (Doc ID 732891.1)

那我們就來觀察一下AWR內 Physical read Requests發現某張table與其index占用相當高，也是使用者反應的SQL內所使用的表。

查一下buffer裝啥囉~

select o.OBJECT_TYPE, substr(o.OBJECT_NAME,1,10)

objname , b.objd , b.status, count(b.objd) from  v$bh b,

dba_objects o where b.objd = o.data_object_id  and o.object_name=<'table_name'>

group by o.object_type,

o.object_name,b.objd, b.status ;

還真的我要的這張表不存在，那當然得做實體I/O,並且另一個session 就產生了這個wait event了

持續調查!

發現buffer cache 與另外一個節點相比小得可憐，也可觀察一下SGA內各個pool爭用的狀況。

結論:

1. 進行SQL調優來降低Physical I/O ，進而減少此wait event

2. 擴大SGA ，設置較大buffer cache size (keep)