ora-03297本质是数据文件末尾存在已分配块，即最高block_id+blocks对应的物理位置超出目标尺寸；需通过dba_extents定位末尾对象，再用shrink space、move或rebuild下压hwm后方可成功resize。
ora-03297 本质是文件末尾有数据，不是空间没释放
执行 alter database datafile '/path/file.dbf' resize 500m 报 ora-03297，说明目标尺寸（500mb）小于该文件中**任意一个已分配块的物理位置**。它不关心你删了多少行、空了多少 mb，只看最高那个 block_id + blocks 落在哪——哪怕只剩一个索引叶子块卡在 999mb 处，就卡死在 1000mb 以下所有 resize 操作。
常见误判：查 dba_free_space 发现空闲空间很大，就以为能缩；或者 TRUNCATE 表后直接 resize，结果照样报错。因为高水位线（HWM）没动，块地址没变。
-
RESIZE是纯文件系统截断，不移动数据、不重组段、不清理元数据 - 它只认物理块号上限，不认逻辑“已用/未用”状态
- 哪怕整个文件只有 10MB 真实数据，只要最高块在 800MB，你就只能 resize 到 ≥800MB
先定位谁在文件末尾占着坑：查最高 block_id
别猜，直接查 dba_extents 找出文件里最靠后的那个块：
SELECT MAX(block_id + blocks) * (SELECT value FROM v$parameter WHERE name = 'db_block_size') AS bytes_used FROM dba_extents WHERE file_id = &file_id;
把结果除以 1024/1024 就是实际已用上限（MB）。如果这个值是 923.4，而你想 resize 到 900M，那必然失败。
- 别只查
MAX(block_id)，漏掉大 extent 的blocks偏移会低估真实占用 - 注意：
dba_extents不包含临时段、undo 段、以及某些延迟清理的 AWR 基表（如WRH$_），它们也可能卡住 HWM - 如果返回空，说明该文件当前无永久段，但可能仍有 active undo 或 temp segment，需结合
v$sort_usage和v$transaction排查
收缩段并下压 HWM：SHRINK SPACE 的前提与陷阱
ALTER TABLE t SHRINK SPACE 是下压单个表 HWM 的主力，但它不是万能钥匙：
- 必须先开
ENABLE ROW MOVEMENT，否则报ORA-10636 - 仅对 ASSM（自动段空间管理）表空间有效；MSSM 表空间不支持 SHRINK
- LOB 字段必须加
CASCADE，否则主表收缩了，LOB 段还钉在原地 - 索引会变
UNUSABLE，得立刻ALTER INDEX i REBUILD，否则后续 DML 可能失败 -
SHRINK SPACE COMPACT只整理块、不移动 HWM；真正下压要再跑一遍SHRINK SPACE
示例流程：
ALTER TABLE scott.emp ENABLE ROW MOVEMENT; ALTER TABLE scott.emp SHRINK SPACE COMPACT; ALTER TABLE scott.emp SHRINK SPACE; ALTER INDEX scott.emp_idx REBUILD;
文件里混着多个对象？得逐个清理或迁移
一个数据文件常含表、索引、LOB、甚至其他用户的对象。SHRINK 表只是动了其中一部分。若最高块属于某个大索引，光 shrink 表毫无意义。
查出是谁占着高位：
SELECT owner, segment_name, segment_type, block_id, blocks FROM dba_extents WHERE file_id = &file_id AND block_id + blocks > &high_water_block ORDER BY block_id DESC;
然后分情况处理：
- 普通表/索引：
ALTER TABLE ... MOVE TABLESPACE new_tbs或ALTER INDEX ... REBUILD TABLESPACE new_tbs - LOB 段：用
ALTER TABLE t MOVE LOB(col) STORE AS (TABLESPACE new_tbs) - 系统对象（如
WRH$_）：不能 move，得调DBMS_SPACE.CLEAN_UP或等 AWR 清理窗口 - UNDO / TEMP 文件：不支持 shrink，只能新建 UNDO 表空间并切换，或重建 TEMP 表空间
最后再试 resize —— 如果仍失败，说明还有隐藏段（比如物化视图日志、IOT overflow 段），得用 DBA_SEGMENTS 全扫一遍。
最麻烦的点往往不在大表，而在没人管的索引或历史遗留的临时段。别跳过 dba_extents 的全量扫描，也别假设 shrink 一次就万事大吉。
