如何处理Oracle中TEMP表空间满的问题？

内容转自：https://blog.csdn.net/sql_ican/article/details/83176289

正常来说，在完成Select语句、create index等一些使用TEMP表空间的排序操作后，Oracle是会自动释放掉临时段a的。但有些有侯我们则会遇到临时段没有被释放，TEMP表空间几乎满的状况，甚至是我们重启了数据库仍没有解决问题。

方法一：重启库

库重启时，Smon进程会完成临时段释放,TEMP表空间的清理操作，不过很多的时侯我们的库是不允许down的,所以这种方法缺少了一点的应用机会，不过这种方法还是很好用的。

方法二：Metalink给出的一个方法

修改一下TEMP表空间的storage参数，让Smon进程观注一下临时段，从而达到清理和TEMP表空间的目的。

SQL>alter tablespace temp increase 1;
SQL>alter tablespace temp increase 0;

方法三：我常用的一个方法

使用如下语句a查看一下认谁在用临时段

SELECT se.username,
sid,
serial#,
sql_address,
machine,
program,
tablespace,
segtype,
contents
FROM v$session se,
v$sort_usage su
WHERE se.saddr=su.session_addr;

SQL> Alter system kill session 'sid,serial#';

把TEMP表空间回缩一下

SQL> Alter tablespace TEMP coalesce;

方法四：使用诊断事件的一种方法,也是被我认为是“杀手锏”的一种方法

确定TEMP表空间的ts#

SQL>select ts#, name from sys.ts$ ;

TS# NAME
-----------------------
0 SYSYEM
1 RBS
2 USERS
3* TEMP
4 TOOLS
5 INDX
6 DRSYS

执行清理操作

SQL>alter session set events 'immediate trace name DROP_SEGMENTS level 4' ;

说明：
temp表空间的TS# 为 3*, So TS#+ 1= 4

其它：

SELECT UPPER(F.TABLESPACE_NAME) "表空间名",
D.TOT_GROOTTE_MB "表空间大小(M)",
D.TOT_GROOTTE_MB - F.TOTAL_BYTES "已使用空间(M)",
TO_CHAR(ROUND((D.TOT_GROOTTE_MB - F.TOTAL_BYTES) / D.TOT_GROOTTE_MB * 100,2),'990.99') "使用比",
F.TOTAL_BYTES "空闲空间(M)",
F.MAX_BYTES "最大块(M)"
FROM (SELECT TABLESPACE_NAME,
ROUND(SUM(BYTES) / (1024 * 1024), 2) TOTAL_BYTES,
ROUND(MAX(BYTES) / (1024 * 1024), 2) MAX_BYTES
FROM SYS.DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME) F,
(SELECT DD.TABLESPACE_NAME,
ROUND(SUM(DD.BYTES) / (1024 * 1024), 2) TOT_GROOTTE_MB
FROM SYS.DBA_DATA_FILES DD
GROUP BY DD.TABLESPACE_NAME) D
WHERE D.TABLESPACE_NAME = F.TABLESPACE_NAME
ORDER BY 4 DESC ；

扩展

SMON

SMON，系统监视。SMON的工作如下：

1，清理临时空间。

2，聚合空闲空间。如果使用dictionary-managed 方式来管理表空间，SMON就要负责把空闲的extent聚合成大的空闲extent。这种情况只有在表空间的管理方式是dictionary-managed ，且参数PCTINCREASE被设置成非零值的时候才会发生。

3，对不可用文件的事务恢复。在数据库启动的时候，SMON会恢复失败的事务，这些事务是在实例恢复或crash恢复的时候被跳过的。例如：在磁盘上某哥文件不可用了，在这个文件又重新可用后，SMON会恢复它。

4，在RAC的单节点故障上进行实例恢复。在RAC 环境下，如果cluster（簇群）中有一个实例失败了（如：实例所在的机器挂掉了），在这个cluster上的其他的节点会打开失败实例的redo log，并恢复失败实例

5，清理OBJ$。OBJ$是个低级别的数据字典，它几乎包含了数据库中所有的objects的entry。多数时候，有的entries的objects已经被删除了，或者当前的entry代表的不再是最新的objects。SMON就负责删除这些entry信息了

6，收缩undo segments。SMON会自动把rollback segment收缩到最优的大小

7，离线rollback segments。DBA可能需要把一个处于active状态的事务的rollback segment离线。此时如果事务正在使用这个已经离线的rollback segment，那么这个segment并未真的离线，而是被标记为“pending offline"。在后台，SMON会一直尝试离线这个segment，直到成功。

此外，SMON还会刷新视图DBA_TAB_MONITORING的统计信息等。SMON会消耗大量的CPU。SMON会定期地，或被其他后台进程唤醒，来执行清理工作。