Oracle临时表空间主要是用来做查询和存放一些缓存的数据的，磁盘消耗的一个主要原因是需要对查询的结果进行排序，如果没有猜错的话，在磁盘空间的（内存）的分配上，Oracle使用的是贪心算法，如果上次磁盘空间消耗达到1GB，那么临时表空间就是1GB，如果还有增长，那么依此类推，临时表空间始终保持在一个最大的上限。Oracle临时表空间暴涨的现象经过分析可能是以下几个方面的原因造成的。
        1. 没有为临时表空间设置上限，而是允许无限增长。但是如果设置了一个上限，最后可能还是会面临因为空间不够而出错的问题，临时表空间设置太小会影响性能，临时表空间过大同样会影响性能，至于需要设置为多大需要仔细的测试。
        2.查询的时候连表查询中使用的表过多造成的。我们知道在连表查询的时候，根据查询的字段和表的个数会生成一个迪斯卡尔积，这个迪斯卡尔积的大小就是一次查询需要的临时空间的大小，如果查询的字段过多和数据过大，那么就会消耗非常大的临时表空间。
       3.对查询的某些字段没有建立索引。Oracle中，如果表没有索引，那么会将所有的数据都复制到临时表空间，而如果有索引的话，一般只是将索引的数据复制到临时表空间中。
       针对以上的分析，对查询的语句和索引进行了优化，情况得到缓解，但是需要进一步测试。

     总结：
       1.SQL语句是会影响到磁盘的消耗的，不当的语句会造成磁盘暴涨。
       2.对查询语句需要仔细的规划，不要想当然的去定义一个查询语句，特别是在可以提供用户自定义查询的软件中。
       3.仔细规划表索引。

而对于LMT管理方式的TEMP表空间，需要重新建立一个新的临时表空间，将所有用户的默认临时表空间指定到新的表空间上，然后offline旧的临时表空间，并drop掉。具体步骤如下：

首先查询用户的缺省临时表空间:

重建新的临时表空间并进行切换:

如果原临时表空间无用户使用(select tablespace_name,current_users,total_blocks,used_blocks,free_blocks,free_blocks/total_blocks from v$sort_segment;),如果是文件系统可以看看文件的时间戳。

我们可以删除该表空间:(如果原临时表空间还有用户在用，你是删除不了这个表空间的！在一次生产环境的临时表空间切换中，原临时表空间始终有用户在上面，即使我关闭了前台程序，也还是有用户，新的临时表空间已经没有用户在使用了。我估计用户进程已经死在原临时表空间了。后来只有重新启动数据库才能把原来旧的临时表空间给删除。）

SQL> drop tablespace temp2;

Tablespace dropped.

SQL> 
SQL> select name from v$tempfile;

NAME
---------------------------------------------------------------
/opt/oracle/oradata/conner/temp1.dbf
/opt/oracle/oradata/conner/temp2.dbf

SQL> select file_name,tablespace_name,bytes/1024/1024 MB,autoextensible
2 from dba_temp_files
3 /

FILE_NAME                              TABLESPACE_NAME              MB AUTOEXTENSIBLE
-------------------------------------- -------------------- ---------- --------------
/opt/oracle/oradata/conner/temp2.dbf   TEMP                         20 NO
/opt/oracle/oradata/conner/temp1.dbf   TEMP                         10 NO

drop tablespace temp including contents and datafiles; --将表空间的内容和数据文件一起删除。

下面是查询在sort排序区使用的执行耗时的SQL:
Select se.username,se.sid,su.extents,su.blocks*to_number(rtrim(p.value))as    Space,tablespace,segtype,sql_text

或是：