一、現象

應用反饋，從本週一（2月21日）開始，每天0-1點之間webedi系統特別慢，1點之後恢復。

二、分析原因

1、 確認是資料庫效能問題

生成2月18日凌晨和2月23日凌晨的awr報告，為同一個時間段的3個小時的報告，其中2月18日DB time為4.57min，2月23日的DB Time為743min。由此可以看出應用反饋的系統慢跟資料庫有關。

2、 最大等待事件

從top 10的等待事件中看，read by other session佔據了83.7%，可以斷定跟這個等待事件有關。

3、 等待事件的中被阻塞者和阻塞者確認

通過dba_hist_active_sess_history檢視中23日凌晨有“read by other session”等待事件的sql。

select a.sql_id,count(*)

from dba_hist_active_sess_history a

where a.sample_time between to_date('20220222 23:00:00','yyyymmdd hh24:mi:ss')

and to_date('20220223 02:00:00','yyyymmdd hh24:mi:ss')

and a.event='read by other session'

and a.con_id=3

group by a.sql_id

order by 2 desc

;

結果如下，大部分為sql_id為agbh2gcvn3q78的sql

通過檢視sql_idagbh2gcvn3q78的阻塞者，發現被同一個sql_id阻塞

select sql_id,count(*)

from dba_hist_active_sess_history a

where a.sample_time between to_date('20220222 23:00:00','yyyymmdd hh24:mi:ss')

and to_date('20220223 02:00:00','yyyymmdd hh24:mi:ss')

and a.con_id=3

and (a.session_id,a.session_serial#) in

(

select distinct t.BLOCKING_SESSION,t.BLOCKING_SESSION_serial#

from dba_hist_active_sess_history t

where t.sample_time between to_date('20220222 23:00:00','yyyymmdd hh24:mi:ss')

and to_date('20220223 02:00:00','yyyymmdd hh24:mi:ss')

and t.event='read by other session'

and t.con_id=3

)

group by sql_id

• order by 2 desc

結果顯示，被同一個sql_id阻塞

三、解決方案

1、 sql_id對應的sql

select dp.* from TD_DELINS_POSITION dp where dp.DELETE_MARK = 'N' and dp.DELINS_ID = :1 order by dp.SCHEDULE_DATE_BEGIN

2、 執行時長和執行計劃

從awr報告中看，該sql執行了63次，每次608秒。從執行計劃看，該sql走的是TD_DELINS_POSITION 表的全表掃描。

Sql執行計劃具體如下：

3、 原因分析

該表7.2G的大小，78032345條記錄。所以每執行一次，效率本來就不高，加上其他session執行這個sql時候的阻塞，造成了執行時間長的現象。

4、 解決方案建議

該表有78032345條記錄，where條件中用到的DELINS_ID有3221214個不同的值，在不用做應用調整的情況下，建議在此列增加一個索引。

Create index xxx on TD_DELINS_POSITION(DELINS_ID);

5、結果

增加索引後的第二天，sql執行事件由原來10分鐘變為0.03秒。