在Oracle数据库中进行order by or group by、索引的创建和重创建、distinct操作、union & intersect & minus sort-merge joins、Analyze 操作、异常等操作时,会产生很多的临时数据。如有一张员工信息表,数据库中是安装记录建立的时间来保存的。如果用户查询时,使用Order BY排序语句指定按员工编号来排序,那么排序后产生的所有记录就是临时数据。通常情况下,Oracle数据库会先将这些临时数据存放到内存的PGA(程序全局区)内。如果数据量太大,PGA存不了,则会放入临时表空间。
默认情况下,临时表空间对所有用户是共享的。当然可以为特殊用户指定单独的临时表空间。临时表空间可以重用。
当临时表空间不足的时候,就会报:ORA-01652:无法通过128(在表空间TEMP中)扩展temp段
这个时候,想当然的就想看看临时表空间的使用情况了:
select tablespace_name, bytes, user_bytes, user_bytes/bytes,file_name from dba_temp_files;
99%?但是其实这个使用率并没有太大的意义,因为当新增一个临时文件(如TEMP02.DBF),然后再跑一次order by,这个使用率就直接飙到99%了。然后换其他的order by语句测试,发现还是可以正常查出数据,说明临时表空间的使用率跟正常的表空间使用率,有所不一样(具体怎么个不一样,就不得而知了)。
也就是说,报错的时候,它的使用率可能是99%;正常运行的时候,使用率也可能是99%。
当报错的时候,就说明临时表空间真的不足了。但由于临时表空间表现为的是dbf文件,那扩展空间也就方便多了。可以直接增大原临时文件,还可以增加临时文件以达到扩大临时表空间的目的。如果你的临时表空间满得太快,这种方式就治标不治本了。可以通过v$sort_usage和v$sort_segment两个视图,分析出是哪些用户和哪些sql导致临时表空间暴涨,再针对性解决。除此之外,优化sql以及对查询的字段建立索引,也可以减少临时表空间的占用。在Oracle中,如果表没有索引,那么会将所有的数据都复制到临时表空间,而如果有索引的话,一般只是将索引的数据复制到临时表空间中。
除了以上这种临时表空间真正满了的情况,查询会报错以外,还有一种情况,也会报同样的错,那就是临时文件offline了。
在v_$tempfile视图中,记录了临时文件的状态,一种是online,一种是offline。当状态为offline的时候,查询也有可能会报这个错。
当然,如果一个临时文件offline了,查询大小时,也是查不出来的。
与临时表空间相关的语句: