今天开发的同事报说有个存储过程老是跑不过去，帮忙看了一下
这个存储过程有两具语句，总是在第二个语句出错
SQL如下：
今天开发的同事报说有个存储过程老是跑不过去，帮忙看了一下
这个存储过程有两具语句，总是在第二个语句出错
SQL如下：
select 201007, t1.prov_id, t2.prov_name, t2.pay_act_num
from vgopdw.tb_det_prov t1,
(select nvl(tb.prov_name, '全国') prov_name,
count(distinct ta.serv_num) pay_act_num
from vgopdw.tdw_mtv_uord_cmon_stat_m ta,
vgopdw.tdw_number_segment_new tb
where exists (select ''
from vgopdw.tdw_mtv_user_use_d tc
where ta.serv_num = tc.serv_num
and tc.deduct_type <> 0
and tc.statis_month = 201007)
and substr(ta.serv_num, 1, 7) = tb.segment
and ord_stat <> '4'
and statis_month = 201007
group by rollup(prov_name)) t2
where t1.prov_name = t2.prov_name
查看这个语句的执行计划：
可以看出TDW_NUMBER_SEGMENT_NEW表的代价很大，MERGE JOIN CARTESIAN笛卡尔连接很慢，分析主要就是这个原因导致产生大量的排序而临时表空间不足,
另外查看了两个分区表，发现7月份的分区都没有统计信息，所以做如下操作：
把TDW_MTV_USER_USE_D和TDW_MTV_UORD_CMON_STAT_M两个表的7月份分区进行分析
这样，调整过后的执行计划如下：
MERGE JOIN CARTESIAN连接也消除，程序运行非常快
是彻底消除MERGE JOIN CARTESIAN需要修改隐藏参数_optimizer_mjc_enabled
SQL> alter system set "_optimizer_mjc_enabled" = false;
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/7490392/viewspace-1037433/ ，如需转载，请注明出处，否则将追究法律责任。
