应先查v$sort_usage确认会话是否真占temp段，再用alter system kill session 'sid,serial#' immediate强杀，若仍killed则kill -9 os进程；残留时用coalesce或重建temp文件。
查临时表空间的活跃会话和对应os进程
临时表空间里的“僵尸会话”通常不是表空间本身的问题，而是某些会话已异常断开但未释放 temp 段（比如排序、哈希连接产生的中间数据），同时其后台进程（ora_*.exe 或 oracle@host）仍在 os 层运行。得先定位到这些残留会话和它们绑定的 os pid。
执行以下查询获取关键信息：
SELECT s.sid, s.serial#, s.username, s.osuser, s.machine, s.program,
p.spid AS os_pid,
s.status, s.sql_id, s.last_call_et
FROM v$session s
JOIN v$process p ON s.paddr = p.addr
WHERE s.username IS NOT NULL
AND s.status = 'INACTIVE'
AND s.last_call_et > 3600 -- 空闲超1小时，大概率是僵尸
AND s.sql_id IS NULL; -- 无当前SQL，进一步佐证
注意：v$session.status = 'INACTIVE' 不代表安全可删，尤其当 s.tempseg_used > 0（需关联 v$sort_usage 查）时，说明它还在占 TEMP 段。
确认会话是否真占用了临时段
只看 v$session 容易误杀——有些会话空闲但刚做完大排序，TEMP 段还没被 Oracle 自动清理。必须验证它是否还在用临时空间：
SELECT s.sid, s.serial#, s.username, u.tablespace, u.blocks * 8 / 1024 AS mb_used FROM v$sort_usage u JOIN v$session s ON u.session_addr = s.saddr WHERE u.tablespace = 'TEMP';
如果结果里有记录，且对应 sid 在上一步查出的“疑似僵尸”列表中，那这个会话就是目标。此时不能直接 ALTER SYSTEM KILL SESSION，因为可能报 ORA-00031: session marked for kill 后卡住——这是常见坑，本质是会话正在清理资源或被挂起。
-
blocks值持续不降，说明会话没真正释放 TEMP 段 - 若
username是应用账号（如APP_USER），优先联系业务确认是否可中断 - 系统用户（如
SYS、DBSNMP）需更谨慎，可能是监控或备份任务残留
安全 Kill 会话并清理 OS 进程
分两步走：先发 KILL SESSION，再根据反馈决定是否强杀 OS 进程。顺序错了容易导致实例级锁或 TEMP 表空间头块损坏。
标准操作：
ALTER SYSTEM KILL SESSION '123,45678' IMMEDIATE;
其中 123 是 sid，45678 是 serial#。加 IMMEDIATE 可跳过等待事务回滚，对僵尸会话更有效。
执行后检查：
- 如果
v$session中该行消失 → OK，TEMP 段会在几秒内自动回收 - 如果仍存在且
status = 'KILLED'→ 需手动干掉 OS 进程 - 查 OS PID：
SELECT spid FROM v$process WHERE addr IN (SELECT paddr FROM v$session WHERE sid = 123);
在数据库服务器上执行：
kill -9 <os_pid></os_pid>
Linux 下用 kill -9，Windows 下用 orakill <oracle_sid><os_pid></os_pid></oracle_sid>。注意：不要用 kill -9 杀 PMON、SMON 等后台进程，只针对查出来的用户进程 spid。
TEMP 表空间未释放的兜底处理
极少数情况下，Kill 后 v$sort_usage 仍有残留记录，DBA_TEMP_FREE_SPACE 显示空闲空间没涨——说明临时段头块状态异常。这时不能重建 TEMP 表空间（风险高），应尝试强制刷新：
ALTER TABLESPACE temp COALESCE;
如果报错 ORA-1652 或无法分配新区，说明有未释放的排序段卡在内存结构里。此时最稳妥的做法是：
- 重启数据库（仅限维护窗口）
- 或执行
ALTER DATABASE TEMPFILE '/path/to/temp01.dbf' DROP INCLUDING DATAFILES;+ 重建（需保证有其他 TEMP 文件可用）
临时表空间不像永久表空间，没有数据字典对象依赖，但重建前务必确认所有应用已停连——否则新连接进来可能因找不到默认 TEMP 而报 ORA-01119。
