Oracle无法删除临时表空间的最常见原因是它仍被设为数据库默认临时表空间，需通过SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE'确认，且必须大小写完全一致；同时须确保v$sort_usage中无占用、OS无进程占用tempfile文件，三者缺一不可。
oracle 无法删除临时表空间，最常见的直接原因是它仍被设为数据库默认临时表空间（default_temp_tablespace）——哪怕你刚执行过 alter database default temporary tablespace 切换，也可能因未生效或残留引用而卡住。
怎么确认当前默认临时表空间是哪个
别信记忆或脚本注释，直接查数据字典：
SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE';
这个值必须和你要删的表空间名**完全一致（大小写敏感）**。如果返回的是 TEMP，但你想删的是 TEMP2，那问题不在这里；如果返回的就是 TEMP2，删不掉就是必然的。
-
DBA_USERS.TEMPORARY_TABLESPACE显示的是用户级默认，不影响DROP TABLESPACE，但若大量用户仍指向该表空间，说明切换没推到底 - RAC 环境下要检查所有实例，
GV$DATABASE或逐个连实例查，避免只改了其中一个节点 - 某些 Oracle 版本（如 11.2.0.4）在 DG 备库上
DEFAULT_TEMP_TABLESPACE可能不同步，需单独验证
为什么切了默认还删不掉：会话缓存与延迟生效
Oracle 不会在你执行 ALTER DATABASE DEFAULT TEMPORARY TABLESPACE 后立刻让所有旧会话“松手”。已有连接仍持有对原临时表空间的句柄，尤其当它们正在做排序、建索引或访问 LOB 时。
- 新会话立即用新默认，但老会话（尤其是长连接应用）仍可能持续使用旧 TEMP，直到事务结束或连接断开
-
v$session中的tempseg_used字段不可靠；更准的是查v$sort_usage并关联v$session：SELECT s.sid, s.username, u.tablespace FROM v$session s, v$sort_usage u WHERE s.saddr = u.session_addr AND u.tablespace = 'TEMP2'; - 即使查询结果为空，也不能排除隐式占用：比如 PL/SQL 包里有未显式关闭的 REF CURSOR + LOB 操作，也会锁住临时段
删不掉时别硬等，先看它卡在哪
执行 DROP TABLESPACE ... 后挂住，不是“慢”，而是被阻塞。立刻查等待事件：
SELECT sid, event, blocking_session FROM v$session WHERE event LIKE 'enq: TS%';
如果看到 enq: TS - contention，基本可断定是 SMON 在回收空间，或某个会话正持有临时段锁。
- 阻塞源常是
SMON进程（smon timer），它在后台清理临时段，但遇到损坏或高位未释放 extent 会卡死 - 也可能是未提交事务中的全局临时表（
GLOBAL TEMPORARY TABLE）行锁，这类锁不会出现在v$lock的常规视图中 - 不要直接
KILL SESSION，尤其对SMON或疑似应用连接，曾有案例 kill 后实例崩溃（ORA-00600）
真正安全删除前的三步确认
这不是流程仪式，而是绕不开的物理约束：
- 确认
database_properties中的DEFAULT_TEMP_TABLESPACE已更新为目标新表空间名 - 确认
v$sort_usage中无任何记录指向待删表空间（不只是空，要查全表） - 确认 OS 层面该 tempfile 路径下无进程正在写入：
lsof | grep temp02.dbf（Linux）或handle.exe temp02.dbf（Windows）
缺一不可。临时表空间不像普通表空间，它的文件一旦被 Oracle 进程打开，OS 就无法删除，而 Oracle 只在 DROP TABLESPACE ... INCLUDING DATAFILES 时才通知操作系统释放句柄——前提是它自己已彻底放手。
