ORA-03297报错本质是临时文件高位存在已分配但空闲的extent，因Oracle将tempfile视为稀疏文件，V$TEMP_SPACE_HEADER.FREE_BLOCKS才反映真实可重用空间；SHRINK SPACE对临时表空间无效，因其不支持ASSM；OFFLINE不可行，唯一安全方法是新建临时表空间、切换默认、确认无活跃使用后DROP INCLUDING CONTENTS AND DATAFILES。
ORA-03297 报错本质是高位空闲块不可回收
执行 ALTER DATABASE TEMPFILE ... RESIZE 时若报 ORA-03297: file contains used data beyond requested RESIZE value，不是语法或权限问题，而是 Oracle 底层把临时文件当作稀疏文件（sparse file）管理：高位可能长期保留已分配但实际未使用的 extent。这些“幽灵占用”块不被 DBA_TEMP_FREE_SPACE 统计，却真实阻断 resize 操作。
验证方式：V$TEMP_SPACE_HEADER.FREE_BLOCKS 才反映当前可立即重用的空闲块数；用它换算出的 free_mb 若远小于 DBA_TEMP_FILES.BYTES，就说明高位碎片已卡死收缩路径。
SHRINK SPACE 对临时表空间完全无效
ALTER TABLESPACE ... SHRINK SPACE 命令在临时表空间上会静默失败或直接报错——因为临时表空间不启用 ASSM（Automatic Segment Space Management），也没有段头（segment header）来跟踪内部碎片。它只按 tempfile 级别分配/释放区（extent），没有“段内收缩”逻辑。
常见误操作：
- 对
TEMP表空间执行SHRINK SPACE KEEP 100M→ 报ORA-03200或无响应 - 试图先
COALESCE再 resize → 该命令对临时表空间无效果，V$TEMP_SPACE_HEADER数据不变
为什么 OFFLINE + RESIZE 走不通
临时文件不支持 OFFLINE 状态，强行执行 ALTER DATABASE TEMPFILE ... OFFLINE 会立即报 ORA-01516（nonexistent log file, datafile or temp file）。即使绕过校验（如通过底层文件系统操作），也无法规避高位 extent 的物理存在——resize 仍会在同一位置失败。
真正有效的空间回收只发生在两个时刻：
- 实例重启后 SMON 清理所有临时段（但生产库通常不允许停机）
- 新建临时表空间并切换默认后，旧 tempfile 彻底脱离所有会话上下文，此时
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES才能真正释放磁盘
重建 TEMP 表空间才是唯一可靠路径
所谓“收缩”，其实是“替换+清理”。整个流程必须满足三个硬条件才能安全落地：
- 新临时表空间已创建且
AUTOEXTEND ON，避免切换瞬间触发ORA-01652 -
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE已生效，且V$SESSION中tempseg_used = 0的旧 TEMP 使用者为零 -
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES中的INCLUDING CONTENTS不可省略，否则残留临时段会锁住文件句柄，导致 OS 层无法回收磁盘空间
注意：临时段释放是 lazy 的，哪怕所有会话都已关闭，SMON 也可能延迟数分钟才真正归还空间。所以 DROP 后立刻检查 df -h 可能仍看不到磁盘释放，需等待几分钟再确认。
