在alert文件中，我們可能會看到這樣的報錯信息：　

WedAug2017:16:372008
ORA-1652:unabletoextendtempsegmentby128intablespaceDBA_TEMP

要解決這個問題，我們首先要導致這個問題的SQL，可能方法有幾種：

（1）設置events

alter system set events '1652 trace name errorstack level 1';

這種方法有一定局限：

1)它不能獲取已發生的1652的錯誤信息，只能對以后出現1652錯誤時生成一個trace文件;

2)用events，不清楚會對數據庫有什么不好的影響。

（2）查詢V$SQL視圖：

如select * from v$sql order by direct_writes/executions desc;

這種方法的局限性是：

1)因為很難知道V$SQL視圖中的SQL執行時間，難以確認具體是那個SQL導致錯誤的

2)引起問題的SQL極有可能已經被age out了

（3）生成錯誤發生時的awr、statspack報表，從報表中的SQL ordered by Reads部分找出SQL

這種方法更不可靠，因為：

1) SQL ordered by Reads讀寫的不一定是臨時表空間

2) awr/statspack報表是根據物理讀的總量排序的，如果導致問題的SQL執行次數少，那也是不會出現在這些報表中的。

（4）查詢awr相關視圖

對于10G來說，這種方法是最可行、最準確的。

　SELECTDISTINCTTO_CHAR(SUBSTR(b.sql_text,1,4000))
　　FROMsys.WRH$_SQLTEXTb
　　WHEREb.sql_idIN
　　(SELECTsql_id
　　FROM
　　(SELECTa.sql_id
　　FROMsys.WRH$_SQLSTATa
　　WHEREa.parsing_schema_nameNOTIN('SYS')
　　ANDa.executions_total>0
　　ANDa.direct_writes_total>0
　　ANDa.SNAP_IDIN
　　(SELECTSNAP_ID
　　FROMsys.WRM$_SNAPSHOT
　　WHEREto_date('2008:08:2017:20:08','yyyy:mm:ddhh24:mi:ss')BETWEENbegin_interval_timeANDend_interval_time
　　)
　　ORDERBYa.direct_writes_total/a.executions_totalDESC
　　)
　　WHERErownum<=10
　　);

基本上，結果中的第一句只要不是insert /*+ append */之類的語句，那么它就極有可能是導致ORA-1652的SQL。

如果是9i，用statspack，也可以用類似的SQL從statspack視圖查到需要的結果