rows算错导致错误的笛卡尔积造成temp不足

今天一哥们发来一条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,这时候逻辑读会大的很离谱

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值