故障現(xiàn)象：臨時表空間不足的問題已經(jīng)報錯過3次，客戶也煩了，前兩次都是同事添加5G的數(shù)據(jù)文件，目前已經(jīng)達到40G，占用臨時表空間主要是distinct 和group by 以及Union all 表數(shù)據(jù)量在200W左右，也不至于把40G的臨時表空間撐爆。

原因分析：既然排序用不了這么多臨時表空間應該是別的原因造成。

從包含故障時間段的AWR報告中可以看出這一階段DBtime蠻高的，并且sql execute elapsed time 竟然占到了99.43%，可以斷定是SQL語句引起的。

通過TOP SQL定位到出問題的SQL

確認是以下SQL引起：

select 'A',
d.explanation, --金融機構(gòu)標識碼
c.account_no, --交易賬號
to_date(a.batchentrydate, 'yyyy-mm-dd'), --發(fā)生日期
c.currencycode, --幣種
SUM(decode(A.Creditdebit, 'C', a.transactionamount, 0)), --當日貸方發(fā)生額
SUM(decode(A.Creditdebit, 'D', a.transactionamount, 0)), --當日借方發(fā)生額
case
when C.Currencycode = 'JPY' Then
Round(c.Ccyledgerbalance, 0)
else
c.ccyledgerbalance
End Balance, --賬戶余額
--b.instcode instcode, --系統(tǒng)虛擬機構(gòu)代號
1 datastatus, --前臺對應的數(shù)據(jù)狀態(tài)
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, --金融機構(gòu)標識碼
c.account_no, --交易賬號
a.batchentrydate, --發(fā)生日期
c.currencycode, --幣種
C.Ccyledgerbalance--系統(tǒng)機構(gòu)代號

觀察并分析其執(zhí)行計劃，貌似也沒有什么問題，因為df_acmov_today（200W左右數(shù)據(jù)）是每天都清空的，沒有索引，全表掃描，nestloops也正常。

但是在執(zhí)行SQL語句時通過腳本監(jiān)控臨時表空間的使用情況，發(fā)現(xiàn)臨時表空間使用率很快就達到了40G左右。又要臨時表空間不足了…

使用dbms_stats.gather_table_stats 分析了下表，然后再去執(zhí)行語句，發(fā)現(xiàn)很快。這下問題清楚了，SQL執(zhí)行計劃錯誤導致的問題。

在對比下先前的SQL執(zhí)行計劃，發(fā)現(xiàn)在執(zhí)行計劃中基數(shù)不對，竟然為1 ，估算的差距太大了。

為什么每天做分析的表（crontab job)最后執(zhí)行計劃卻不對？

最后竟然是這樣：使用crontab 在凌晨2:30對表做分析，但是早上6點。其他任務對表做了，truncate 和Insert into 從而導致該原因。

最終調(diào)整計劃任務時間問題完全解決。

最新評論