問題現象;生產環境報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_ID cku6z254k95z5, child number 0 ------------------------------------- select coalesce(sum(u.money),0) from t1 u left 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 < to_date(:2,'yyyy-mm-dd hh24:mi:ss') and 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關閉了並行後，業務恢復正常。