gpt4 book ai didi

关于SQL执行计划错误导致临时表空间不足的问题

转载 作者:qq735679552 更新时间:2022-09-29 22:32:09 25 4
gpt4 key购买 nike

CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章关于SQL执行计划错误导致临时表空间不足的问题由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.

故障现象:临时表空间不足的问题已经报错过3次,客户也烦了,前两次都是同事添加5G的数据文件,目前已经达到40G,占用临时表空间主要是distinct 和group by 以及Union all 表数据量在200W左右,也不至于把40G的临时表空间撑爆.

原因分析:既然排序用不了这么多临时表空间应该是别的原因造成.

从包含故障时间段的AWR报告中可以看出这一阶段DBtime蛮高的,并且sql execute elapsed time 竟然占到了99.43%,可以断定是SQL语句引起的.

关于SQL执行计划错误导致临时表空间不足的问题

通过TOP SQL定位到出问题的SQL 。

关于SQL执行计划错误导致临时表空间不足的问题

确认是以下SQL引起:

select 'A',  d.explanation, --金融机构标识码  c.account_no, --交易账号  to_date(a.batchentrydate, 'yyyy-mm-dd'), --发生日期  c.currencycode, --币种  SUM(decode(A.Creditdebit, 'C', a.transactionamount, 0)), --当日贷方发生额  SUM(decode(A.Creditdebit, 'D', a.transactionamount, 0)), --当日借方发生额  case  when C.Currencycode = 'JPY' Then  Round(c.Ccyledgerbalance, 0)  else  c.ccyledgerbalance  End Balance, --账户余额  --b.instcode instcode, --系统虚拟机构代号  1 datastatus, --前台对应的数据状态  c.account_no || c.currencycode || '2013-01-04',  to_date('2013-01-04', 'yyyy-mm-dd')  from df_cust C  left join (select distinct ACCOUNTBRANCH,  DESCRIPTION,  MASTERNO,  CURRENCYCODE,  ACCOUNT_NUMBER,  SEQNO,  ACCT_CLASS_CODE,  PRODUCTCODE,  VALUEDT_YYYY,  VALUEDT_MM,  VALUEDT_DD,  BATCHENTRYDATE,  VALUEDT_YYYYMMDD,  NARRATIONPOST,  TRANSACTIONAMOUNT,  CREDITDEBIT,  ACCOUNTBRANCH1,  SEGMENTCODE,  REFERENCENUMBER,  NARRATIONTRAN,  BATCHNUMBER,  GLDEPTID,  ARMCODE,  EXTREFNO,  MAKERID,  CHECKERID,  CHANNELID,  TRANSACTION_AMT_IN_USD,  ACCSHORTNAME,  ARMNAME,  SEGNAME,  TXNCODE,  REVERSALFLAG,  EBBSREFERENCE,  TRANSTYPECODE,  CUSTOMERRATE,  ADVTREASURYFLAG,  VA_FLAG  from df_acmov_today  where Creditdebit in ('C', 'D')) a on a.account_number =  c.account_no  Left Join Da_Mid_Acc_Gl_Dic D On D.Source = A.Accountbranch  Where exists (select 1  from acc.t_base_account b  where b.account = c.account_no  and b.currence_code = c.currencycode)  and a.account_number is not null  and c.account_no like '0%'  group by d.explanation, --金融机构标识码  c.account_no, --交易账号  a.batchentrydate, --发生日期  c.currencycode, --币种  C.Ccyledgerbalance--系统机构代号 。

观察并分析其执行计划,貌似也没有什么问题,因为df_acmov_today(200W左右数据)是每天都清空的,没有索引,全表扫描,nestloops也正常.

但是在执行SQL语句时通过脚本监控临时表空间的使用情况,发现临时表空间使用率很快就达到了40G左右。又要临时表空间不足了… 。

使用dbms_stats.gather_table_stats 分析了下表,然后再去执行语句,发现很快。这下问题清楚了,SQL执行计划错误导致的问题.

在对比下先前的SQL执行计划,发现在执行计划中基数不对,竟然为1 ,估算的差距太大了.

为什么每天做分析的表(crontab job)最后执行计划却不对?

最后竟然是这样:使用crontab 在凌晨2:30对表做分析,但是早上6点。其他任务对表做了,truncate 和Insert into 从而导致该原因.

最终调整计划任务时间问题完全解决.

最后此篇关于关于SQL执行计划错误导致临时表空间不足的问题的文章就讲到这里了,如果你想了解更多关于关于SQL执行计划错误导致临时表空间不足的问题的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com