关于SQL执行计划错误导致临时表空间不足的问题
故障现象：临时表空间不足的问题已经报错过3次，客户也烦了，前两次都是同事添加5g的数据文件，目前已经达到40g，占用临时表空间主要是distinct 和group by 以及union all 表数据量在200w左右，也不至于把40g的临时表空间撑爆。
原因分析：既然排序用不了这么多临时表空间应该是别的原因造成。
从包含故障时间段的awr报告中可以看出这一阶段dbtime蛮高的，并且sql execute elapsed time 竟然占到了99.43%，可以断定是sql语句引起的。
通过top 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 从而导致该原因。
最终调整计划任务时间问题完全解决。