Oracle临时表空间主要是用来做查询和存放一些缓存的数据的,磁盘消耗的一个主要原因是需要对查询的结果进行排序,如果没有猜错的话,在磁盘空间的(内存)的分配上,Oracle使用的是贪心算法,如果上次磁盘空间消耗达到1GB,那么临时表空间就是1GB,如果还有增长,那么依此类推,临时表空间始终保持在一个最大的上限。Oracle临时表空间暴涨的现象经过分析可能是以下几个方面的原因造成的。
1. 没有为临时表空间设置上限,而是允许无限增长。但是如果设置了一个上限,最后可能还是会面临因为空间不够而出错的问题,临时表空间设置太小会影响性能,临时表空间过大同样会影响性能,至于需要设置为多大需要仔细的测试。
2.查询的时候连表查询中使用的表过多造成的。我们知道在连表查询的时候,根据查询的字段和表的个数会生成一个迪斯卡尔积,这个迪斯卡尔积的大小就是一次查询需要的临时空间的大小,如果查询的字段过多和数据过大,那么就会消耗非常大的临时表空间。
3.对查询的某些字段没有建立索引。Oracle中,如果表没有索引,那么会将所有的数据都复制到临时表空间,而如果有索引的话,一般只是将索引的数据复制到临时表空间中。
针对以上的分析,对查询的语句和索引进行了优化,情况得到缓解,但是需要进一步测试。
总结:
1.SQL语句是会影响到磁盘的消耗的,不当的语句会造成磁盘暴涨。
2.对查询语句需要仔细的规划,不要想当然的去定义一个查询语句,特别是在可以提供用户自定义查询的软件中。
3.仔细规划表索引。
如果临时表空间是temporary的,空间不会释放,只是在sort结束后被标记为free的,如果是permanent的,由SMON负责在sort结束后释放,都不用去手工释放的。查看有哪些用户和SQL导致TEMP增长的两个重要视图:
v$sort_usage和v$sort_segment
对于非LMT管理方式的TEMP表空间,最简单的方法是Metalink给出的一个方法:
修改一下TEMP表空间的storage参数,让Smon进程观注一下临时段,从而达到清理和TEMP表空间的目的。
SQL>alter tablespace temp default storage(pctincrease 1);
SQL>alter tablespace temp default storage(pctincrease 0);
而对于LMT管理方式的TEMP表空间,需要重新建立一个新的临时表空间,将所有用户的默认临时表空间指定到新的表空间上,然后offline旧的临时表空间,并drop掉。具体步骤如下:
首先查询用户的缺省临时表空间:
[oracle@jumper oracle]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Wed Apr 12 11:11:43 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production With the Partitioning option JServer Release 9.2.0.4.0 - Production
SQL> select username,temporary_tablespace from dba_users;
USERNAME TEMPORARY_TABLESPACE ------------------------------ ------------------------------ SYS TEMP2 SYSTEM TEMP2 OUTLN TEMP2 EYGLE TEMP2 CSMIG TEMP2 TEST TEMP2 REPADMIN TEMP2 ......
13 rows selected.
SQL> select name from v$tempfile;
NAME --------------------------------------------------------------------- /opt/oracle/oradata/conner/temp02.dbf /opt/oracle/oradata/conner/temp03.dbf |
重建新的临时表空间并进行切换:
SQL> create temporary tablespace temp tempfile '/opt/oracle/oradata/conner/temp1.dbf' size 10M;
Tablespace created.
SQL> alter tablespace temp add tempfile '/opt/oracle/oradata/conner/temp2.dbf' size 20M;
Tablespace altered.
SQL> alter database default temporary tablespace temp;
Database altered.
SQL> select username,temporary_tablespace from dba_users;
USERNAME TEMPORARY_TABLESPACE ------------------------------ ------------------------------ SYS TEMP SYSTEM TEMP OUTLN TEMP EYGLE TEMP CSMIG TEMP TEST TEMP REPADMIN TEMP .......
13 rows selected. |
如果原临时表空间无用户使用(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
from v$sort_usage su,v$parameter p,v$session se,v$sql s
where p.name='db_block_size' and su.session_addr=se.saddr and s.hash_value=su.sqlhash and s.address=su.sqladdr
order by se.username,se.sid
或是:
Select su.username,su.Extents,tablespace,segtype,sql_text
From v$sort_usage su,v$sql s
Where su.SQL_ID = s.SQL_ID