alter tablespace coalesce 在本地管理表空间（extent_management local）中基本无效，仅对遗留的字典管理表空间（extent_management dictionary）且pctincrease≠0时才可能生效；执行后dba_free_space无变化即表明未触发逻辑。
ALTER TABLESPACE COALESCE 在本地管理表空间中基本无效
这条命令对当前主流的 EXTENT_MANAGEMENT LOCAL 表空间不起作用——它不会合并空闲区，不改变 DBA_FREE_SPACE 的行数或块分布，多数情况下直接报 ORA-1145 或静默失败。Oracle 10g 起已淘汰字典管理（DMT）表空间，而 COALESCE 唯一真正生效的场景，仅限于仍存在的 DMT 表空间（EXTENT_MANAGEMENT DICTIONARY），且需满足 PCTINCREASE != 0 等苛刻条件。
你执行完 ALTER TABLESPACE ts_name COALESCE 后查 DBA_FREE_SPACE，如果 BLOCK_ID 和 BYTES 没变化，不是操作没跑完，而是根本没触发逻辑。
怎么确认你的表空间是否支持 COALESCE
先查类型：
SELECT TABLESPACE_NAME, EXTENT_MANAGEMENT, SEGMENT_SPACE_MANAGEMENT FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = 'YOUR_TS';
只有当 EXTENT_MANAGEMENT = 'DICTIONARY' 时才可能生效；若为 'LOCAL'，就别再试了。
-
SEGMENT_SPACE_MANAGEMENT = 'AUTO'（即 ASSM）是本地管理的标配，进一步确认COALESCE无意义 - 即使误写成
ALTER TABLESPACE ... COALESCE，Oracle 也不会警告，只会忽略或报错 - DMT 表空间在 12c+ 中无法新建，存量极少，通常只出现在老旧迁移遗留库中
真正在意“相邻空闲区”时该看什么
想验证是否存在物理连续的空闲 extent，不要依赖直觉，用这个查询肉眼扫：
SELECT FILE_ID, BLOCK_ID, BLOCKS, BYTES FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME = 'YOUR_TS' ORDER BY FILE_ID, BLOCK_ID;
如果某行的 BLOCK_ID + BLOCKS == 下一行的 BLOCK_ID，说明它们物理相邻——这才是 COALESCE 唯一能处理的情况。但注意：
- 只在同一
FILE_ID内有效，跨文件的永远不合并 - 中间哪怕隔一个已分配 block，就断开，无法合并
- 本地管理表空间的位图本身已隐含连续性判断，
DBA_FREE_SPACE返回的是“逻辑空闲单元”，不是碎片源
比 COALESCE 有用得多的实际操作
表空间“分配不出大 extent”，根源几乎总在段级：HWM 卡住、空闲块散落在高水位线下、ASSM 位图未及时重用小块。此时该做的是：
- 对大表执行
ALTER TABLE t SHRINK SPACE CASCADE（需先ENABLE ROW MOVEMENT），它下调 HWM 并整理内部空闲块 - 重建索引：
ALTER INDEX i REBUILD ONLINE，消除叶块分裂和逻辑碎片 - 含 LOB 的表要单独处理：
ALTER TABLE t MODIFY LOB (col) (SHRINK SPACE) - 收缩后必须跟
DBMS_STATS.GATHER_TABLE_STATS，否则优化器仍按旧统计量估算
反复执行 COALESCE 不仅无效，还会让你跳过真正该查的 DBA_SEGMENTS、V$SEGSTAT 和 ASH 中的段级等待信号。
