ID51"."ACC_ID")
45 - access("T"."ACC_ID"="TMPID50"."ACC_ID")
47 - access("T"."ACC_ID"="TMPID58"."ACC_ID")
49 - access("T"."ACC_ID"="TMPID78"."ACC_ID")
51 - access("T"."ACC_ID"="TMPID79"."ACC_ID")
53 - access("T"."ACC_ID"="TMPID57"."ACC_ID")
55 - access("T"."ACC_ID"="TMPID77"."ACC_ID")
57 - filter("T"."FLAG"='1')
63 - access("T"."CG_ID"="B"."CG_ID" AND "B"."IPSN_NO"=TO_NUMBER("T"."IPSN_NO"))
65 - access("T"."ACC_ID"="TMPID78"."ACC_ID")
67 - access("T"."ACC_ID"="TMPID53"."ACC_ID")
69 - access("T"."ACC_ID"="TMPID65"."ACC_ID")
71 - access("T"."ACC_ID"="TMPID81"."ACC_ID")
73 - access("T"."ACC_ID"="TMPID56"."ACC_ID")
75 - access("T"."ACC_ID"="TMPID43"."ACC_ID")
77 - access("T"."ACC_ID"="TMPID77"."ACC_ID")
79 - access("T"."ACC_ID"="TMPID82"."ACC_ID")
81 - access("T"."ACC_ID"="TMPID69"."ACC_ID")
83 - access("T"."CNTR_NO"="TMP25"."CNTR_NO")
85 - access("T"."CNTR_NO"="TMPNO30"."CNTR_NO")
87 - access("T"."ACC_ID"="TMPID44"."ACC_ID")
89 - access("T"."ACC_ID"="TMPID2046"."ACC_ID")
91 - filter(("T"."FLAG"='2' OR "T"."FLAG"='5'))
93 - access("T"."ACC_ID"="TMPID51"."ACC_ID")
95 - access("T"."ACC_ID"="TMPID50"."ACC_ID")
97 - access("T"."ACC_ID"="TMPID58"."ACC_ID")
99 - access("T"."ACC_ID"="TMPID79"."ACC_ID")
101 - access("T"."ACC_ID"="TMPID57"."ACC_ID")
102 - access("T"."CNTR_NO"="TMP46"."CNTR_NO")
104 - access("T"."CNTR_NO"="TMPNO69"."CNTR_NO")
106 - access("T"."CNTR_NO"="TMPNO30"."CNTR_NO")
108 - access("T"."CNTR_NO"="TMPNO43"."CNTR_NO")
110 - access("T"."CNTR_NO"="TMPNO44"."CNTR_NO")
112 - access("T"."CNTR_NO"="TMPNO56"."CNTR_NO")
114 - access("T"."CNTR_NO"="TMPNO81"."CNTR_NO")
116 - access("T"."CNTR_NO"="TMPNO4"."CNTR_NO")
118 - access("T"."CNTR_NO"="TMPNO65"."CNTR_NO")
120 - access("T"."CNTR_NO"="TMPNO71"."CNTR_NO")
122 - access("T"."CNTR_NO"="TMPNO53"."CNTR_NO")
124 - access("T"."CNTR_NO"="TMPNO51"."CNTR_NO")
126 - access("T"."CNTR_NO"="TMPNO50"."CNTR_NO")
128 - access("T"."CNTR_NO"="TMPNO58"."CNTR_NO")
130 - access("T"."ACC_ID"="TMPID78"."ACC_ID")
132 - access("T"."ACC_ID"="TMPID79"."ACC_ID")
134 - access("T"."ACC_ID"="TMPID57"."ACC_ID")
136 - filter(("T"."FLAG"='4' OR "T"."FLAG"='6'))
139 - access("T"."CG_ID"="B"."CG_ID" AND "B"."IPSN_NO"=TO_NUMBER("T"."IPSN_NO"))
140 - filter("T"."FLAG"='2')
143 - access("T"."CNTR_NO"="TMPNO30"."CNTR_NO")
145 - access("T"."CNTR_NO"="TMP3"."CNTR_NO")
245 rows selected.
是一个insert select。然后其中的select是 一堆union all 组合起来的。通过粗略一看，看的我头晕眼花。
给对方打电话，询问情况，得知开发说以前跑的比现在快
我让对方跑select * from table(dbms_xplan.display_awr('0ah5a8dbk28fh'),null,null,'advanced'); 并将内容发给我
其中存在三个执行计划， cost 分别有三个，当前跑的这个是其中cost最大的那个
第一、我不在现场
第二、现在没时间，也没办法详细优化
所以我选择的方案，就是通过coe_xfr_sql_profile.sql 来将执行计划绑定为cost最小的那个!
后来对方领导决定先不kill，因为我和对方说，这里是DML操作，回滚时间会比较长。
这里反应出了问题，首先开发连select的速度都没测，就直接insert，真是。。而且，再弱也应该知道开并行吧？这里也没有开并行
等周二详细优化的时候，思路如下：
1、先检查统计信息，并检查这个SQL产生三个执行计划的主要原因
2、将union all 拆开，分别优化每个SQL（如果能用with as 尝试运用）
3、优化好查询速度之后 开并行跑。这里注意，看并行DML 要打开session级别的并行DML
未完待续……