c.account_no, --交易账号
NARRATIONTRAN,
MAKERID,
from df_cust C
SUM(decode(A.Creditdebit, 'D', a.transactionamount, 0)), --当日借方发生额
SEQNO,
EXTREFNO,
PRODUCTCODE,
Where exists (select 1
and c.account_no like '0%'
GLDEPTID,
NARRATIONPOST,
CUSTOMERRATE,
left join (select distinct ACCOUNTBRANCH,
DESCRIPTION,
from acc.t_base_account b

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

else
TRANSACTION_AMT_IN_USD,

VALUEDT_YYYYMMDD,
Round(c.Ccyledgerbalance, 0)
ACCT_CLASS_CODE,

--b.instcode instcode, --系统虚拟机构代号
SEGMENTCODE,
to_date('2013-01-04', 'yyyy-mm-dd')
REVERSALFLAG,
Left Join Da_Mid_Acc_Gl_Dic D On D.Source = A.Accountbranch
1 datastatus, --前台对应的数据状态

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

ARMNAME,

EBBSREFERENCE,
CREDITDEBIT,
and b.currence_code = c.currencycode)
where b.account = c.account_no
REFERENCENUMBER,

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

ADVTREASURYFLAG,

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

CHANNELID,
ACCSHORTNAME,
when C.Currencycode = 'JPY' Then

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

ACCOUNTBRANCH1,
a.batchentrydate, --发生日期
c.account_no || c.currencycode || '2013-01-04',
where Creditdebit in ('C', 'D')) a on a.account_number =
VALUEDT_YYYY,
End Balance, --账户余额

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

ARMCODE,
group by d.explanation, --金融机构标识码
and a.account_number is not null
BATCHNUMBER,
c.currencycode, --币种
c.account_no
ACCOUNT_NUMBER,
VALUEDT_MM,
c.currencycode, --币种

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

CHECKERID,
c.ccyledgerbalance

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

MASTERNO,

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

c.account_no, --交易账号
SEGNAME,
TXNCODE,
CURRENCYCODE,
TRANSTYPECODE,
case

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

C.Ccyledgerbalance--系统机构代号

VA_FLAG
TRANSACTIONAMOUNT,
SUM(decode(A.Creditdebit, 'C', a.transactionamount, 0)), --当日贷方发生额

select 'A',
VALUEDT_DD,
from df_acmov_today
d.explanation, --金融机构标识码
BATCHENTRYDATE,

确认是以下SQL引起：

to_date(a.batchentrydate, 'yyyy-mm-dd'), --发生日期