今天一哥们发来一条sql说一直不出结果,最后报错:ORA-01652: 无法通过 128 (在表空间 TEMP 中) 扩展 temp 段
select tran_info.*,
rp.mcc_typ_id,
urm2.org_no,
trim(urm2.rate_type) as rate_type,
(case
when tran_info.oldSXF < urm2.max_fee_amt then
'0'
when tran_info.oldSXF >= urm2.max_fee_amt then
'1'
else
'0'
end) as iSCap
from biz_test.T_BIZ_SINGLE_FEE_TEMP tran_info,
(select mst.*
from biz_test.T_BIZ_MERC_SCOPE_TEMP mst
where mst.merc_id not in
(select merc_id
from biz_test.T_BIZ_SPECIAL_MERC bsm
where bsm.spec_type = '2'
and bsm.is_used = '1')) urm2,
biz_test.t_mcc rp
where tran_info.merc_id = urm2.merc_id
and tran_info.mcc_cd = rp.mcc_cd
解释:执行计划里面有笛卡尔积MERGE JOIN CARTESIAN,单看SQL的话,是不可能产生笛卡尔积的,所以这个问题统计信息不准导致ROWS算成了1(越是小表ROWS越有可能算成1)。优化器则认为其走的正确的笛卡尔积【什么是正确的笛卡尔积,什么是错误的笛卡尔积?】假设一个表的数据是30w ,被算成了1 走笛卡尔积,那么结果集就要被放大30w倍,所以导致temp不足报错也在情理之中
处理方法:
1.加hint,根据表的大小让其强制走hash 或者 nl
写hint很容易眼高手低,而且优化器的版本不同hint的格式也有微小的差别
2.收集统计信息:系统自带有,DBA也会做相应的策略总结:
rows算错的情况在执行计划中经常存在,大多都是因为rows算小了,一般会引起两种错误的执行计划rows算成1 错误的笛卡尔积,执行计划里面笛卡尔积关键字和rowsrows算小了本来应该HASH 结果走了NL,这时候逻辑读会大的很离谱
版权声明:本文为Skybig1988原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。