個人網站: https://kxodia.com
今天在第一個節點發現有wait event read by other session 與DB file sequential read幾乎佔據了80% 的DB time。
研究一下這是兩個session引發的問題，以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)
