国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 數據庫 > Oracle > 正文

關于SQL執行計劃錯誤導致臨時表空間不足的問題

2024-08-29 13:55:23
字體:
來源:轉載
供稿:網友

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

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

從包含故障時間段的AWR報告中可以看出這一階段DBtime蠻高的,并且sql execute elapsed time 竟然占到了99.43%,可以斷定是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 從而導致該原因。

最終調整計劃任務時間問題完全解決。

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 大连市| 盐源县| 封丘县| 无极县| 靖西县| 长寿区| 红河县| 陈巴尔虎旗| 花垣县| 佛坪县| 佳木斯市| 大理市| 鄱阳县| 新乡市| 许昌县| 西华县| 宁安市| 高唐县| 清河县| 临洮县| 邵阳县| 凌海市| 蕉岭县| 永清县| 旌德县| 武定县| 高雄市| 扎兰屯市| 绍兴市| 连州市| 滕州市| 正阳县| 曲阜市| 厦门市| 汨罗市| 阿荣旗| 进贤县| 孝昌县| 湖北省| 新丰县| 巴中市|