服务器之家

服务器之家 > 正文

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

时间:2019-11-21 15:19     来源/作者:数据库教程网

故障现象:临时表空间不足的问题已经报错过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 从而导致该原因。

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

相关文章

热门资讯

玄元剑仙肉身有什么用 玄元剑仙肉身境界等级划分
玄元剑仙肉身有什么用 玄元剑仙肉身境界等级划分 2019-06-21
男生常说24816是什么意思?女生说13579是什么意思?
男生常说24816是什么意思?女生说13579是什么意思? 2019-09-17
配置IIS网站web服务器的安全策略配置解决方案
配置IIS网站web服务器的安全策略配置解决方案 2019-05-23
Nginx服务器究竟是怎么执行PHP项目
Nginx服务器究竟是怎么执行PHP项目 2019-05-24
运维必须知道的关于云服务器的十个问题
运维必须知道的关于云服务器的十个问题 2019-05-24
返回顶部