生產SQL語句突然變慢問題的示例分析

183次閱讀

共計 3134 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章主要為大家展示了“生產 SQL 語句突然變慢問題的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“生產 SQL 語句突然變慢問題的示例分析”這篇文章吧。

在客戶生產環境中，突然某條 SQL 語句非常慢，無法跑出結果，以下是診斷過程記錄：

1、定位 sql_id：
select sql_id from v$sql where sql_text like %xxx%
sql_id
———————–
564s6g59axuk4

2、統計 AWR 視圖中，該語句執行效率：
set linesize 155
col execs for 999,999,999
col avg_etime for 999,999.999
col avg_lio for 999,999,999.9
col begin_interval_time for a30
col node for 99999
break on plan_hash_value on startup_time skip 1
select ss.snap_id, ss.instance_number node, begin_interval_time, sql_id, plan_hash_value,
nvl(executions_delta,0) execs,
(elapsed_time_delta/decode(nvl(executions_delta,0),0,1,executions_delta))/1000000 avg_etime,
(buffer_gets_delta/decode(nvl(buffer_gets_delta,0),0,1,executions_delta)) avg_lio
from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
where sql_id = nvl(sql_id , 564s6g59axuk4)
and ss.snap_id = S.snap_id
and ss.instance_number = S.instance_number
and executions_delta 0
order by 1, 2, 3
/
SNAP_ID NODE BEGIN_INTERVAL_TIME SQL_ID PLAN_HASH_VALUE EXECS AVG_ETIME AVG_LIO
———- —– —————————— ————- ————— ———- ———- ———-
20001 1 26-10 月 -17 08.00.30.657 上午 564s6g59axuk4 2005782661 30 14.1517821 1865567.83
20025 1 27-10 月 -17 08.00.20.698 上午 564s6g59axuk4 2005782661 27 13.3753969 1844812.18
20049 1 28-10 月 -17 08.00.49.876 上午 564s6g59axuk4 3677205750 24 11.9541753 1659475.33
20050 1 28-10 月 -17 09.00.03.143 上午 564s6g59axuk4 3677205750 3 13.4740316 2533988.33
20073 1 29-10 月 -17 08.00.19.029 上午 564s6g59axuk4 3677205750 21 8.46142976 1441061.47
20097 1 30-10 月 -17 08.00.09.581 上午 564s6g59axuk4 2810744384 21 9.88548957 1340974.47
20121 1 31-10 月 -17 08.00.14.292 上午 564s6g59axuk4 2810744384 24 9.11253825 1414630.87
20145 1 01-11 月 -17 08.00.43.216 上午 564s6g59axuk4 2005782661 21 10.182155 1393004.14
20169 1 02-11 月 -17 08.00.09.892 上午 564s6g59axuk4 342558915 9 280.462698 16771588.3
20173 1 02-11 月 -17 12.00.24.738 下午 564s6g59axuk4 2005782661 3 19.7334523 3270556
20174 1 02-11 月 -17 01.00.28.307 下午 564s6g59axuk4 2005782661 9 12.2578504 1799912.11
20193 1 03-11 月 -17 08.00.38.295 上午 564s6g59axuk4 342558915 9 244.750394 12790174.7
20199 1 03-11 月 -17 02.00.09.612 下午 564s6g59axuk4 342558915 1 3515.82643 178237676
20200 1 03-11 月 -17 03.00.03.620 下午 564s6g59axuk4 2797223102 1 1660.86502 89454616
從報告中可以看出，執行計劃中出現一些錯誤，查看錯誤的執行計劃：

3、統計一下數據庫執行計劃
select distinct SQL_ID,PLAN_HASH_VALUE,to_char(TIMESTAMP, yyyymmdd hh34:mi:ss) TIMESTAMP
from dba_hist_sql_plan
where SQL_ID= 564s6g59axuk4 order by TIMESTAMP;
SQL_ID PLAN_HASH_VALUE TIMESTAMP
————- ————— —————–
564s6g59axuk4 2005782661 20170714 11:30:09
564s6g59axuk4 3677205750 20170715 08:16:24
564s6g59axuk4 2810744384 20171030 08:18:15
564s6g59axuk4 342558915 20171102 08:18:12
564s6g59axuk4 2797223102 20171103 15:07:06

4、錯誤 SQL 的執行計劃：
col options for a30
col operation for a40
col object_name for a20
select plan_hash_value,id,LPAD(, 2 * (depth – 1)) || OPERATION || ||DECODE(ID, 0, Cost = || POSITION) OPERATION ,
options,object_name,CARDINALITY,cost,to_char(TIMESTAMP, yyyymmdd hh34:mi:ss) TIMESTAMP
from DBA_HIST_SQL_PLAN
where sql_id = 564s6g59axuk4
and plan_hash_value= 342558915
order by ID,TIMESTAMP;
分析執行計劃中，選擇錯誤的索引，以渠道日期進行 NL，造成執行效率低下。

以上是“生產 SQL 語句突然變慢問題的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！

正文完