今天开发的同事报说有个存储过程老是跑不过去,帮忙看了一下
这个存储过程有两具语句,总是在第二个语句出错
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博客 ” ,链接:http://blog.itpub.net/7490392/viewspace-1037433/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/7490392/viewspace-1037433/