ORA-03297报错本质是高水位（HWM）卡在文件尾部，即某段的最后一个extent位于目标resize位置之后；需先查dba_extents中最高block_id，结合db_block_size计算理论最小尺寸（如hwm_block×8192÷1024÷1024向上取整），再定位并移动/重建越界对象（如ALTER TABLE ... MOVE、ALTER INDEX ... REBUILD），最后验证v$datafile.bytes是否生效且autoextensible未开启。
ORA-03297报错本质是高水位（HWM）卡在文件尾部
不是空间不够，而是某个段（表、索引、lob等）的最后一个extent落在了你想缩到的位置之后。哪怕整个表空间只用了100mb，只要有一行数据或一个索引块位于第9.5gb处，你就不能把文件缩到9.4gb以下。alter database datafile ... resize只能裁掉**完全空闲**的末尾区域，不支持“打洞”式压缩。
先算出安全的最小可缩尺寸
别靠猜或看dba_free_space总和——它只告诉你有多少空闲块，不告诉你这些空闲块是否连续、是否在尾部。真正决定下限的是最高使用的块号：
SELECT file_id, MAX(block_id + blocks - 1) AS hwm_block FROM dba_extents WHERE file_id = &file_id GROUP BY file_id;-
SHOW PARAMETER db_block_size查出块大小（通常是8192） - 计算：
hwm_block * db_block_size / 1024 / 1024→ 得到单位为MB的理论最小尺寸（向上取整）
比如hwm_block = 1213833，块大小8192 → 1213833 * 8192 / 1024 / 1024 ≈ 9483.07 MB → 至少得缩到9484M，缩到9483M就必然报ORA-03297。
定位并移动/重建越界对象
知道HWM在哪，下一步就是找出谁占着那儿：
SELECT owner, segment_name, segment_type, extent_id FROM dba_extents WHERE file_id = &file_id AND block_id + blocks - 1 >= &hwm_block;- 常见罪魁：大表的最后一个分区、未维护的索引、LOB段、或者
SYS用户下的系统对象（如REGISTRYINFO这种） - 对普通表：
ALTER TABLE owner.table_name MOVE TABLESPACE same_tbs ONLINE;（12c+支持ONLINE，减少锁表时间） - 对索引：
ALTER INDEX owner.idx_name REBUILD ONLINE;或先DROP再CREATE - 对LOB段：需指定
STORAGE子句重定位，不能只MOVE表
注意：SHRINK SPACE对堆表有效，但对索引无效；COALESCE对本地管理表空间基本没用，别白费力气。
临时表空间或SYSTEM表空间要换思路
SYSTEM或TEMP表空间里的对象不能随便MOVE或DROP。比如SYSTEM里残留的大段，TRUNCATE或DROP后HWM还在，文件不缩：
- 临时表空间：建新temp表空间，
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE new_temp;，再DROP TABLESPACE old_temp INCLUDING CONTENTS AND DATAFILES; - SYSTEM表空间：除非确认是测试环境且无业务依赖，否则优先用
DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_QUOTAS或联系Oracle支持。强行删系统对象风险极高 - 如果对象属于
AUD$、LOGMNR等，先清理对应日志或归档，再尝试收缩
最易被忽略的点：缩容后必须验证v$datafile.bytes确实变小，且dba_data_files里该文件的autoextensible状态没被意外打开——否则下次写入又自动涨回去。
