您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“生產(chǎn)SQL語(yǔ)句突然變慢問(wèn)題的示例分析”,內(nèi)容簡(jiǎn)而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“生產(chǎn)SQL語(yǔ)句突然變慢問(wèn)題的示例分析”這篇文章吧。
在客戶生產(chǎn)環(huán)境中,突然某條SQL語(yǔ)句非常慢,無(wú)法跑出結(jié)果,以下是診斷過(guò)程記錄:
1、定位sql_id:
select sql_id from v$sql where sql_text like '%xxx%'
sql_id
-----------------------
564s6g59axuk4'
2、統(tǒng)計(jì)AWR視圖中,該語(yǔ)句執(zhí)行效率:
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
從報(bào)告中可以看出,執(zhí)行計(jì)劃中出現(xiàn)一些錯(cuò)誤,查看錯(cuò)誤的執(zhí)行計(jì)劃:
3、統(tǒng)計(jì)一下數(shù)據(jù)庫(kù)執(zhí)行計(jì)劃
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、錯(cuò)誤SQL的執(zhí)行計(jì)劃:
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;
分析執(zhí)行計(jì)劃中,選擇錯(cuò)誤的索引,以渠道日期進(jìn)行NL,造成執(zhí)行效率低下。
以上是“生產(chǎn)SQL語(yǔ)句突然變慢問(wèn)題的示例分析”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對(duì)大家有所幫助,如果還想學(xué)習(xí)更多知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。