oracle 并行用索引,分区索引并行导致的性能问题
問題現象;生產環境報ORA-17144=statement handle not executed
然后我把sql抓出來手工運行一遍執行計劃如下：----------------------------------------------------------
Plan?hash?value:?644608605
-------------------------------------------------------------------------------------------------------------------------------
|?Id??|?Operation??????|?Name??????|?Rows??|?Bytes?|?Cost?(%CPU)|?Time?????|?Pstart|?Pstop?|
-------------------------------------------------------------------------------------------------------------------------------
|???0?|?SELECT?STATEMENT??????|???????|?????1?|????75?|???120K(1)|?00:24:10?|???????|???????|
|???1?|??SORT?AGGREGATE???????|???????|?????1?|????75?|????|??????|???????|???????|
|???2?|???NESTED?LOOPS??????|???????|?58896?|??4313K|???120K(1)|?00:24:10?|???????|???????|
|???3?|????NESTED?LOOPS???????|???????|?58896?|??4313K|???120K(1)|?00:24:10?|???????|???????|
|???4?|?????PARTITION?RANGE?SINGLE??????|???????|?58896?|??2300K|??2984(1)|?00:00:36?|????12?|????12?|
|???5?|??????TABLE?ACCESS?BY?LOCAL?INDEX?ROWID|?t1???|?58896?|??2300K|??2984(1)|?00:00:36?|????12?|????12?|
|*??6?|???????INDEX?RANGE?SCAN??????|?idx_1?|?58896?|???????|??2984(1)|?00:00:36?|????12?|????12?|
|*??7?|?????INDEX?UNIQUE?SCAN??????|?t2_UNIQUE1???|?????1?|???????|?????1(0)|?00:00:01?|???????|???????|
|*??8?|????TABLE?ACCESS?BY?GLOBAL?INDEX?ROWID?|?t2??????|?????1?|????35?|?????2(0)|?00:00:01?|?ROWID?|?ROWID?|
-------------------------------------------------------------------------------------------------------------------------------
這個執行計劃非常正常，400ms返回結果，于是我抓了出問題時的awr，發現這個sql跑了2分鐘，于是我猜測執行計劃和當前運行的執行計劃不一致，然后sql_id 抓取了當時運行的執行計劃如下
SQL>?set?pages?200?lines?200;
SELECT?*
FROM?TABLE(dbms_xplan.display_cursor(sql_id??????????=>?'1hqcmrpa790c3',
cursor_child_no?=>?0,
4?????????????????????????????????????????format??????????=>?'ALL?ALLSTATS?LAST?NOTE?ADVANCED?-projection'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_IDcku6z254k95z5,?child?number?0
-------------------------------------
select?coalesce(sum(u.money),0)?from?t1?uleft
join?t2?r?on?u.orderform_flow_no?=?r.serialnumber?????WHERE
u.create_time?>=?to_date(:1,'yyyy-mm-dd?hh24:mi:ss')???and
u.create_time?
r.service_id?=?'unicomhb'????and?r.status?=?2
Plan?hash?value:?28991375
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|?Id??|?Operation???|?Name???|?E-Rows?|E-Bytes|?Cost?(%CPU)|?E-Time???|?Pstart|?Pstop?|?TQ??|IN-OUT|?PQ?Distrib?|??OMem?|??1Mem?|?Used-Mem?|?Used-Tmp|
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|???0?|?SELECT?STATEMENT???|???|????|????|100K(100)|????|????|????|?????|????|????|?|?|????|??????|
|???1?|??SORT?AGGREGATE????|???|??1?|?75?|?|????|????|????|?????|????|????|?|?|????|??????|
|*??2?|???PX?COORDINATOR???|???|????|????|?|????|????|????|?????|????|????|?|?|????|??????|
|???3?|????PX?SEND?QC?(RANDOM)???|?:TQ10002???|??1?|?75?|?|????|????|????|??Q1,02?|?P->S?|?QC?(RAND)??|?|?|????|??????|
|???4?|?????SORT?AGGREGATE???|???|??1?|?75?|?|????|????|????|??Q1,02?|?PCWP?|????|?|?|????|??????|
|*??5?|??????FILTER???|???|????|????|?|????|????|????|??Q1,02?|?PCWC?|????|?|?|????|??????|
|*??6?|???????HASH?JOIN????|???|??87509?|??6409K|100K??(1)|?00:20:12?|????|????|??Q1,02?|?PCWP?|????|??1740K|??1638K|?2076K?(0)|??????|
|???7?|????????PX?RECEIVE???|???|??87509?|??3418K|127???(0)|?00:00:02?|????|????|??Q1,02?|?PCWP?|????|?|?|????|??????|
|???8?|?PX?SEND?HASH???|?:TQ10001???|??87509?|??3418K|127???(0)|?00:00:02?|????|????|??Q1,01?|?P->P?|?HASH??|?|?|????|??????|
|???9?|??PX?PARTITION?RANGE?ITERATOR???|???|??87509?|??3418K|127???(0)|?00:00:02?|KEY?|KEY?|??Q1,01?|?PCWC?|????|?|?|????|??????|
|??10?|???TABLE?ACCESS?BY?LOCAL?INDEX?ROWID|?t1???|??87509?|??3418K|127???(0)|?00:00:02?|KEY?|KEY?|??Q1,01?|?PCWP?|????|?|?|????|??????|
|*?11?|????INDEX?RANGE?SCAN???|?idx_1?|??87509?|????|127???(0)|?00:00:02?|KEY?|KEY?|??Q1,01?|?PCWP?|????|?|?|????|??????|
|??12?|????????BUFFER?SORT???|???|????|????|?|????|????|????|??Q1,02?|?PCWC?|????|???126M|??3809K|???97M?(0)|??113K|
|??13?|?PX?RECEIVE???|???|???9157K|305M|100K??(1)|?00:20:10?|????|????|??Q1,02?|?PCWP?|????|?|?|????|??????|
|??14?|??PX?SEND?HASH???|?:TQ10000???|???9157K|305M|100K??(1)|?00:20:10?|????|????|?????|?S->P?|?HASH??|?|?|????|??????|
|??15?|???PARTITION?RANGE?ALL???|???|???9157K|305M|100K??(1)|?00:20:10?|??1?|?19?|?????|????|????|?|?|????|??????|
|*?16?|????TABLE?ACCESS?FULL???|?t2???|???9157K|305M|100K??(1)|?00:20:10?|??1?|?19?|?????|????|????|?|?|????|??????|
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
果不其然，上面全是并行掃描，這里也不用糾結這個并行為什么會導致ora-17144錯誤，然后我立馬想到用sql profile 將執行計劃固定住，但是絕對不太合理，至于為什么并行還要找到問題說在，
于是我查詢了表和該表索引的并行度，發現分區index上開啟了并行，問題找到了，通過
alter index index_name noparallel關閉了并行后，業務恢復正常。
總結
以上是生活随笔為你收集整理的oracle 并行用索引,分区索引并行导致的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《零基础》MySQL GROUP BY
- 下一篇： 摄像头夜间拍摄画面有拖影_让客厅秒变健身