alter database tempfile ... resize 总是报 ora-03297，因为 oracle 要求目标大小不低于已分配空间总量（非已用空间），临时文件末尾存在未释放区；正确方法是使用 shrink space 或 shrink tempfile，并确保本地管理、无活跃排序、keep 值≥对齐后的实际占用。
为什么 ALTER DATABASE TEMPFILE ... RESIZE 总是报 ORA-03297
因为临时文件末尾存在已分配但未释放的区（extent），哪怕当前没活跃排序，V$TEMP_EXTENT_POOL 显示真实占用远小于 dba_temp_files.bytes。Oracle 的 RESIZE 要求目标大小 ≥ 当前已分配空间总量，不是“已用”空间——所以看起来空，却根本缩不动。
常见错误现象就是执行后立刻返回：ORA-03297: file contains used data beyond requested RESIZE value。这不是权限或语法问题，是机制限制。
该行为在 Oracle 11g 及以上所有版本中一致，与 autoextensible 设置无关。
用 SHRINK SPACE 或 SHRINK TEMPFILE 才是正解
Oracle 11g 引入了真正的在线收缩能力，但仅适用于本地管理（segment_space_management = 'LOCAL'）的临时表空间。必须先确认这点：
SELECT tablespace_name, segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'TEMP';
确认后可选两种方式：
-
ALTER TABLESPACE TEMP SHRINK SPACE KEEP 512M;：尝试收缩整个表空间下所有临时文件，保留至少 512MB 物理空间（注意：KEEP 是底线，不是目标；若当前已用 600MB，则实际收缩到 600MB） -
ALTER TABLESPACE TEMP SHRINK TEMPFILE '/path/to/temp01.dbf' KEEP 256M;：只收缩指定单个文件，适合多文件表空间中某一个严重膨胀的场景
二者都会等待正在使用的 extent 归还；如果命令长时间无响应，说明有长事务、大排序或未提交操作仍在占用临时段（查 v$sort_usage 和 v$session 确认）。
收缩前必须检查的三件事
跳过这些，收缩可能卡住、静默失败，甚至误删活跃数据：
- 确认临时表空间是本地管理（非字典管理）——字典管理不支持 shrink
- 确认当前无活跃排序：查
v$sort_usage，确保没有行返回；若有，需 kill 对应 session（ALTER SYSTEM KILL SESSION 'sid,serial#';） - 确认 KEEP 值 ≥ 当前真实已用空间向上对齐到 extent 边界（否则命令静默无效）。可先查真实用量：
SELECT tablespace_name, SUM(used_blocks * block_size) / 1024 / 1024 AS "MB USED" FROM v$tempseg_usage t, dba_temp_files f WHERE t.tablespace = f.tablespace_name AND f.file_name = '/path/to/temp01.dbf' GROUP BY tablespace_name;
实在缩不动？重建是唯一可靠 fallback
当 shrink 卡死、或表空间是字典管理、或你不敢动线上环境时，重建更可控：
- 新建临时表空间：
CREATE TEMPORARY TABLESPACE temp_new TEMPFILE '/new/path/temp_new01.dbf' SIZE 512M AUTOEXTEND ON; - 切换默认：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_new; - 等旧表空间空闲（查
v$sort_usage为空）后，再 drop：DROP TABLESPACE TEMP INCLUDING CONTENTS AND DATAFILES;
注意：drop 前必须确保无 session 还在用它，否则操作系统级文件可能残留（尤其 AIX/Linux 下文件句柄未释放），重启实例才能彻底清理。
真正容易被忽略的是：KEEP 值不是“想留多少就写多少”，而是硬性下限；而 v$sort_usage 的实时性依赖于事务提交或会话断开——未提交的大排序，哪怕 SQL 已执行完，临时段仍被持有。
