oracle临时表空间使用率长期100%非故障而是设计行为，因tempfile扩展后高位extent不自动回收，真实空闲需查v$temp_space_header；重建表空间（新建→切换→确认无残留→删除）是唯一可靠在线解法。
Oracle临时表空间使用率长期显示100%不是故障，是设计行为：tempfile一旦扩展，Oracle不会自动收缩文件大小，即使所有排序结束，高位已分配的区（extent）仍被标记为“已分配但空闲”，dba_temp_files统计的是已分配总量，不是实时活跃占用。
查不到活跃会话但使用率还是100%
这是最典型的假满现象。关键要看 v$temp_space_header 而不是 dba_free_space 或 dba_temp_files：
-
v$sort_usage返回空，且v$session中没有tempseg_used > 0的会话 → 基本可排除真实活跃排序 -
SELECT tablespace_name, free_blocks FROM v$temp_space_header若free_blocks = 0→ 确认是高位 extent 未释放，属于“已分配但空闲” -
SELECT * FROM v$tempseg_usage WHERE session_num NOT IN (SELECT sid FROM v$session)若有结果 → 存在孤儿临时段，需等 SMON 清理（默认每5分钟轮询一次）
为什么 alter database tempfile ... resize 总失败
因为 resize 要求目标尺寸必须大于文件中最后一个已使用块的位置。Oracle 不允许截断高位已分配的 extent —— 即使那些 extent 当前没数据。
- 执行
alter database tempfile '/path/to/temp01.dbf' resize 1g时若报ORA-03297→ 明确说明高位有未释放的区 - 盲目 kill 会话后立刻 resize 仍可能失败：客户端重连发起新排序，会直接写到旧
tempfile高位，进一步固化占用边界 -
alter tablespace temp shrink space在任何 Oracle 版本中都无效：临时表空间不支持 shrink 操作
重建 TEMP 表空间才是最小风险在线解法
无需重启数据库，但必须确保无大规模排序或建索引任务正在运行（否则会触发 ORA-01652）。步骤顺序不能错：
- 新建中转临时表空间：
CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '/u01/oradata/ORCL/temp02.dbf' SIZE 1024M AUTOEXTEND ON NEXT 100M MAXSIZE 8G - 切换默认：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2 - 确认旧
TEMP无残留使用：SELECT sid, serial#, username FROM v$session WHERE tempseg_used > 0 AND tablespace = 'TEMP'结果必须为空 - 删除旧表空间：
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES（INCLUDING CONTENTS必须加，否则删不掉临时段）
重建后旧 tempfile 物理文件被彻底移除，空间立即释放。注意：临时表空间不能“只删 tempfile、留表空间”，那样会导致后续任何排序操作直接失败。
