read by other session的優化記錄

【背景】以下是一個ERP資料庫的AWR報告，初看資料庫挺繁忙的，DB Time/Elapsed的比值接近20，再深入往下看發現資料庫的read by other session事件明顯，以下是經過一系列的分析解決了read by other session等待事件的問題；

 

Top 5等待事件

 

【問題分析一】read by other session產生的原因：發生在一個資料塊正在被讀進buffer，而其它session此時也要請求這個資料塊的時候。這個事件10G以前被歸類在buffer busy wait的其他類目中。（說明有多個會話同時在對一個表進行讀操作）

 

查詢AWR報告中跟I/O有關的SQL語句

 

 

【問題分析二】以上的分析可以給出一個大概的範圍，需要繼續結合ASH報告或者直接檢視當前的session等待情況

1、查詢相應的SQL_ID select  distinct  sql_id  From  v$session Where  event in('read by other session', 'db file sequential read');   2、檢視相應的SQL語句和執行計劃 select * from table(dbms_xplan.display_awr('SQL_ID'));

 

【問題分析三】當前ERP系統是SAP，SAP系統對於系統的效能監控和診斷提供了一系列強大的TC，通過執行SM66，剛好可以看到同時有很多並行的SESSION在執行

 

【問題原因】經過一系列的分析和判斷，終於找到問題的根源，由於後臺配置了一個有問題的JOB。

該JOB每30分鐘執行一次

 

但是歷史記錄顯示，每次JOB執行的時間到超過10個小時，這個場景我們可以想象一下：

8點00分，執行job，然後這個job會進行select 表A的操作，且一直在循壞操作；

 

8點30分，這個job又啟動了，也執行select表A的操作，且一直在循壞操作；

9點00分，再次啟動job，進行select表A的操作，且一直在循壞操作；

 

這個場景下來肯定就會出現：一個資料塊正在被讀進buffer，而其它session此時也要請求這個資料塊的時候。所以read by other session的等待事件就產生了。

 

【解決方法】找到問題的原因後，把當前JOB的情況發給業務部門進行調整，調整後每次執行在10分鐘以內，相應的read by other session的等待事件也就沒有了。

 

【總結】剛開始系統資料量小的時候，一些操作不加條件、沒有索引執行起來都不會影響系統的，但是隨著資料量的增加如果沒有對系統進行定期檢查的話，那麼系統就是會越來越慢；

這也是很多系統執行到一定程度就感覺硬體撐不住的原因，其實是由於粗狂式的系統管理，導致系統的資源過度浪費導致的。

想想一本字典目錄就是那麼幾頁，如果沒有用好這個目錄的話，就像進行海量的資料查詢不用索引操作；

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

本文作者：JOHN，某上市公司DBA，業餘時間專注於資料庫的技術管理，從管理的角度去運用技術。

技術部落格：獵人筆記                                                資料庫技術群：367875324 （請備註資料庫型別）

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12679300/viewspace-1745779/，如需轉載，請註明出處，否則將追究法律責任。