今天用戶那邊執(zhí)行一個很簡單的SQL，輸出結(jié)果集也才幾萬條，涉及三表，最大也才100萬數(shù)據(jù)量，結(jié)果卻報了表空間不足的情況，理論來說，這樣的SQL怎么也不應(yīng)該吃這么多臨時表空間。

創(chuàng)新互聯(lián)建站是一家以成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、品牌設(shè)計、軟件運維、營銷推廣、小程序App開發(fā)等移動開發(fā)為一體互聯(lián)網(wǎng)公司。已累計為成都水電改造等眾行業(yè)中小客戶提供優(yōu)質(zhì)的互聯(lián)網(wǎng)建站和軟件開發(fā)服務(wù)。

查詢臨時表空間的使用情況：

select USERNAME,SESSION_NUM,SQL_ID,TABLESPACE,SEGTYPE,BLOCKS*8192/1024/1024||' MB' as MB from v$sort_usage order by 6 desc

v$sort_usage顯示給定實例的每個排序段的信息，只有發(fā)生在臨時表空間的操作才會更新該視圖。這里不僅僅記載排序動作，只要在臨時表空間操作就會記錄，而且排序發(fā)生在內(nèi)存，也不會更新該視圖的。

一般固定思維我都會認為此SQL有問題，然后我執(zhí)行了一次之后，立馬就拋異常了，我此時即時反應(yīng)過來不對勁，因為SQL如果要暫用臨時表空間很多，也是逐步一點一點索取空間占用的，這異常拋出太快了，轉(zhuǎn)而我就去查詢了dba_temp_files,果然是因為設(shè)計的問題，臨時表空間創(chuàng)建的不合理，真的是空間太小的緣故：

alter database tempfile xxx autoextend on next 200m maxsize unlimited;

臨時表空間占用的幾大場景：

1、order by or group by ；

2、索引的創(chuàng)建和重創(chuàng)建；

3、distinct、SORT-MERGE JOINS、HASH JOIN等操作；

4、union & intersect & minus sort-merge joins；

5、其他異常操作