ORA-03297报错本质是高水位线（HWM）卡在文件尾部，即某段最后一个extent位于目标resize位置之后；需先查dba_extents中最高block_id并结合db_block_size计算理论最小尺寸（向上取整），再定位越界对象执行MOVE或REBUILD，最后RESIZE释放文件系统空间。
ORA-03297报错本质是HWM卡在文件尾部，不是空间不够
ORA-03297不是因为“没空闲空间”，而是某段（表、索引、LOB等）的最后一个extent落在你指定的RESIZE位置之后。哪怕dba_free_space显示有10GB空闲，只要最高已用块号（block_id + blocks - 1）对应的位置在9.5GB处，你就不能缩到9.4GB以下——Oracle只允许裁掉**完全空闲且连续位于末尾**的区域。
先算出安全的最小可缩尺寸，别靠dba_free_space总和猜
查最高已用块号：
SELECT MAX(block_id + blocks - 1) AS hwm_block FROM dba_extents WHERE file_id = &file_id;
再结合块大小换算成MB（向上取整）：
SELECT CEIL(&hwm_block * &db_block_size / 1024 / 1024) AS min_resize_mb FROM dual;
-
&file_id从v$datafile查；&db_block_size用SHOW PARAMETER db_block_size确认（通常为8192） - 结果就是理论下限，比如算出来是9483.07MB，必须至少写
9484M，写9483M必报错 -
dba_free_space只告诉你有多少空闲块，不告诉你是否在尾部；v$datafile.bytes只是物理大小，不能直接当收缩依据
定位并移动/重建越界对象，不能只SHRINK SPACE
SHRINK SPACE只回收段内碎片，不移动HWM；真正卡住的是段的物理分配位置。先找出谁占着高水位附近：
SELECT owner, segment_name, segment_type, extent_id FROM dba_extents WHERE file_id = &file_id AND block_id + blocks - 1 >= &hwm_block;
- 普通堆表：
ALTER TABLE owner.table_name MOVE TABLESPACE same_tbs ONLINE;（12c+支持ONLINE） - 索引：
ALTER INDEX owner.idx_name REBUILD ONLINE;或DROP后重建 - LOB段：必须显式重定位，例如
ALTER TABLE t MODIFY LOB (c) (STORAGE (TABLESPACE new_tbs)); - SYSTEM/TEMP表空间里的对象不能MOVE，需特殊处理（如建新temp表空间再切换）
RESIZE命令本身容易翻车的细节
语法简单，但单位、权限、时机都可能失败：
- 单位默认是KB，写
1024M会报错，必须写1G或1048576K - 必须在OPEN或MOUNT状态执行，RAC环境需确保所有实例可见该文件，否则可能触发
ORA-01157 - 目标大小建议比计算值多留1MB余量，避免刚收缩完就被写入触发自动扩展
- 执行
SHRINK SPACE后立即RESIZE失败？检查是否有未提交事务、延迟段未刷新、或LOB没加CASCADE
最常被忽略的点：COALESCE对本地管理表空间基本无效，SHRINK不等于文件变小，RESIZE才是释放文件系统空间的最后一步。
