ORA-01652：無法通過128(在表空間temp中)擴展temp段 解決方法
(2016-10-21 16:49:53)今天在做一個查詢的時候，報了一個“ORA-01652無法通過128(在表空間temp中)擴展temp段”
ORA-01652: 無法通過128（在表空間TOSTEMP中）擴展 temp 段
ORA-06512: 在"Funcking", line 60
ORA-06512: 在line 1
錯誤解決網上也有一些相關的資料。我的實驗解決方法是這樣的：
1.查看表空間使用率（包括臨時表空間）
select * from (
Select a.tablespace_name,
to_char(a.bytes/1024/1024,'99,999.999') total_bytes,
to_char(b.bytes/1024/1024,'99,999.999') free_bytes,
to_char(a.bytes/1024/1024 - b.bytes/1024/1024,'99,999.999') use_bytes,
to_char((1 - b.bytes/a.bytes)*100,'99.99') || '%' use
from (select tablespace_name,
sum(bytes) bytes
from dba_data_files
group by tablespace_name) a,
(select tablespace_name,
sum(bytes) bytes
from dba_free_space
group by tablespace_name) b
where a.tablespace_name = b.tablespace_name
union all
select c.tablespace_name,
to_char(c.bytes/1024/1024,'99,999.999') total_bytes,
to_char( (c.bytes-d.bytes_used)/1024/1024,'99,999.999') free_bytes,
to_char(d.bytes_used/1024/1024,'99,999.999') use_bytes,
to_char(d.bytes_used*100/c.bytes,'99.99') || '%' use
from
(select tablespace_name,sum(bytes) bytes
from dba_temp_files group by tablespace_name) c,
(select tablespace_name,sum(bytes_cached) bytes_used
from v$temp_extent_pool group by tablespace_name) d
where c.tablespace_name = d.tablespace_name
)
order by tablespace_name
2.查看文件是否自動擴展
select d.file_name,d.tablespace_name,d.autoextensible from dba_data_files d
如果想查看臨時表空間文件是否自動擴展
select d.file_name,d.tablespace_name,d.autoextensible from dba_temp_files d;
3.對臨時文件進行擴展。
1）TOSTEMP表空間使用率接近100%，對它進行擴展。
SQL> alter database tempfile 'C:xxxxxx\TOSTEMP01.DBF'resize 500M;
2）若是發現 表空間使用率接近100%，且不可擴展修改文件自動可擴展性
alter database datafile 'E:xxxxxxESCALADE.ORA' autoextend on;
3）修改可擴展上限為無限制
SQL> alter database tempfile ‘/u01/app/oracle/oradata/orcl/temp01.dbf’ autoextend on next 5m maxsize unlimited;
正常的解決方案，請參考：http://www.atmarkit.co.jp/fdb/rensai/ora_admin/03/ora_admin02.html
很遺憾把tempfile 改到3G也不行。
根據網上看到有些朋友又碰到這樣的問題，說是只要進行analyze就可以。我也進行analyze分析一下。
EXEC DBMS_UTILITY.ANALYZE_SCHEMA('USER','ESTIMATE');
附DBMS_UTILITY.ANALYZE_SCHEMA作用：
このプロシージャは、スキーマ內にあるすべての表、クラスタおよび索引でANALYZEコマンドを実行します。このプロシージャを使用して、非オプティマイザ統計情報を収集します。
然后再執行存儲過程，等待結果......(19:53開始)
20:40,結果出來了，還是不行。值得進一步探討。
經過這次的失敗后，我在想問題到底在哪里？
我把這個出錯的SQL文從存儲過程摘出來，進行分析。
1）從SQL結構中沒發現任何問題。
2）在sqlplus里面跟了一下執行計划。
在經過30分鍾左右的等待后，這一執行計划顯示了出來。看得真是嚇了一跳。
buffer消耗超過5000G，都不敢相信自己的眼睛，byte位數算了幾遍，確實是特別大。
看到執行計划我也就知道原因是什么了，臨時空間怎么加也不會夠呀。
以上是實驗告一段落，對於這種問題的解決方法，如下：
1）首先對存儲過程的執行計划進行分析。
看占用多大的臨時空間，有沒有優化的余地，怎么優化。
（這就是網上說碰巧用analyze命令，結果通過的原因，應該是analyze命令，讓執行計划發生了改變）
2）優化后的臨時空間大於現有的臨時空間的話，擴張臨時空間。
以上算是我對ORA-01652錯誤的診斷分析。