故障现象:临时表空间不足的问题已经报错过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',--当日借方发生额 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 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,--交易账号 a.batchentrydate,--币种 C.Ccyledgerbalance--系统机构代号
观察并分析其执行计划,貌似也没有什么问题,因为df_acmov_today(200W左右数据)是每天都清空的,没有索引,全表扫描,nestloops也正常。
但是在执行SQL语句时通过脚本监控临时表空间的使用情况,发现临时表空间使用率很快就达到了40G左右。又要临时表空间不足了…
为什么每天做分析的表(crontab job)最后执行计划却不对?
最后竟然是这样:使用crontab 在凌晨2:30对表做分析,但是早上6点。其他任务对表做了,truncate 和Insert into 从而导致该原因。
最终调整计划任务时间问题完全解决。 (编辑:李大同)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|