今天在第一個節點發現有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。
那我們就來觀察一下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)