【转】ORACLE 临时表空间使用率过高的原因及解决方案 在数据库的日常学习中，发现公司生产数据库的默认临时表空间 temp 使用情况达到了 30G，使用率达到了 100%； 待调整为 32G 后，使用率还是为 100%，导致磁盘空间使用紧张。根据临时表空间的主要是对临时数据进行排序和缓存临时数据等特性，待重启数据库后， temp会自动释放。于是想通过重启数据库的方式来缓解这种情况，但是重启数据库之后，发现临时表空间 temp 的使用率还是 100%，一点没变。虽然运行 中应用暂时没有报什么错误，但是这在一定程度上存在一定的隐患，有待解决该问题。由于临时表空间主要使用在以下几种情况： 1、order by or group by (disc sort 占主要部分)； 2、索引的创建和重创建； 3、distinct 操作； 4、union & intersect & minus sort-merge joins； 5、Analyze 操作； 6、有些异常也会引起TEMP 的暴涨。 Oracle 临时表空间暴涨的现象经过分析可能是以下几个方面的原因造成的： 1. 没有为临时表空间设置上限，而是允许无限增长。但是如果设置了一个上限，最后可能还是会面临因为空间不够而出错的问题，临时表空间设置太小会影响性能，临时表空间过大同样会影响性能，至于需要设置为多大需要仔细的测试。 2.查询的时候连表查询中使用的表过多造成的。我们知道在连表查询的时候，根据查询的字段和表的个数会生成一个迪斯卡尔积，这个迪斯卡尔积的大小就是一次查询需要的临时空间的大小，如果查询的字段过多和数据过大，那么就会消耗非常大的临时表空间。 3.对查询的某些字段没有建立索引。Oracle 中，如果表没有索引，那么会将所有的数据都复制到临时表空间，而如果有索引的话，一般只是将索引的数据复制到临时表空间中。 针对以上的分析，对查询的语句和索引进行了优化，情况得到缓解，但是需要进一步测试。 总结： 1.SQL 语句是会影响到磁盘的消耗的，不当的语句会造成磁盘暴涨。 2.对查询语句需要仔细的规划，不要想当然的去定义一个查询语句，特别是在可以提供用户自定义查询的软件中。 3.仔细规划表索引。如果临时表空间是 temporary 的，空间不会释放，只是在 sort 结束后被标记为 free 的，如果是 permanent 的，由 SMON 负责在 sort 结束后释放，都不用去手工释放的。查看有哪些用户和 SQL 导致 TEMP 增长的两个重要视图：v$ sort_usage 和v$sort_segment。 通过查询相关的资料，发现解...
