溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

生產(chǎn)SQL語(yǔ)句突然變慢問(wèn)題的示例分析

發(fā)布時(shí)間:2022-03-07 11:18:22 來(lái)源:億速云 閱讀:198 作者:小新 欄目:關(guān)系型數(shù)據(jù)庫(kù)

這篇文章主要為大家展示了“生產(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è)資訊頻道!

向AI問(wèn)一下細(xì)節(jié)

免責(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)容。

sql
AI