read by other session在undo所想

今天系統反應較慢，出現了大量的read by other session事件，檢視該sql語句並沒有最佳化方案。可以採取的就是改寫sql語句了（其中後續採取的也就是修改sql語句的功能）。不過個人比較關心的是這個read by other session為什麼會大量出現在file 2上。

db file sequential read

46.31

"25","118758","1"

0.01

file#

block#

blocks

read by other session

42.56

"2","22197","52"

0.02

file#

block#

class#

相比以前做awr報告，其實如果系統某段時間反應較慢，做ash報告也是一個很不錯的選擇，ash的報告相對於小範圍時間內的取樣更加清晰明確，從ash報告的top事件裡面，發覺都在file 2一個回滾段上。

Read by other session等待事件主要集中在了file 2上，也就是回滾表空間的回滾段上，這個資訊檢視了undo表空間的大小和使用程度，發現已經資料檔案使用率達到了98%，由於使用的預設的單個資料檔案而且設定的自動擴充套件無限制，資料檔案已經達到了30g。

對於回滾段的使用比較集中，也就會出現兩個會話同時讀取資料從disk到buffer時出現的，該等待事件在10g中單獨列出，看來是由於session讀取資料時把資料併發的讀取導致，也算作一個熱點快事件。（熱點塊不一定是普通的block，也有可能是undo造成的）

如果調整上肯定優先採用對sql語句進行調整，減小邏輯讀，也就減小了資料讀取的競爭了，加大buffer cache大小、減小磁碟讀取的機率，因為記憶體的讀取比磁碟快很多，相應的競爭也就會減少很多。

下面介紹一下經常用的查詢熱點塊的sql語句：

SELECT E.OWNER, E.SEGMENT_NAME, E.SEGMENT_TYPE

FROM DBA_EXTENTS E,

(SELECT *

FROM (SELECT ADDR, TS#, FILE#, DBARFIL, DBABLK, TCH

FROM X$BH

ORDER BY TCH DESC)

WHERE ROWNUM < 11) B

WHERE E.RELATIVE_FNO = B.DBARFIL

AND E.BLOCK_ID <= B.DBABLK

AND E.BLOCK_ID + E.BLOCKS > B.DBABLK;

再透過v$sqltext等檢視聯合segment_name來獲取熱點塊的sql語句，看是否對其進行適量的調整和修改。

還是回到上述問題file 2競爭壓力大，新建了undo表空間，分散了多個資料檔案，讓其減少同一時間使用同一undo段的機率，不過仔細想想這個很可能只能輕微的減小壓力，甚至可以說微乎其微，不過還是建議分開多個資料檔案和磁碟來減小IO衝突。

這個案例其實說到底我們應該透過sql語句來修改，對於一些IO消耗比較大的sql語句進行程式上面的修改，讓其減少讀取undo段的機率，也就是最大的程度的減少了file 2的read by other session的競爭。

調整了程式碼和重新設定了sga引數，啟動的時候一段時間內出現了Buffer exterminate事件，

該事件是由於在asmm下sga的動態自動調整導致的，該事件描述的是會話在讀取已經收縮的sga中的buffer導致，該事件出現時很有可能是因為shared pool突然使用機率增加了，通常隨之出現的是一系列的硬解析，想想後續重新啟動了資料庫和調整了程式碼，硬解析增加了shared pool使用需求增加。

如果該等待事件確定為引起了效能的平靜，那麼可以採取解決方案是：禁用asmm功能，或者設定buffer cache的最小值防止過度收縮。不過該等待事件一般不會出現較長的時間。

[@more@]