alter tablespace ... coalesce 对本地管理表空间（lmt）无效，因其仅适用于已淘汰的字典管理表空间；lmt使用位图管理空闲区，无需且无法合并碎片，执行该命令会被静默忽略或报ora-1145。
ALTER TABLESPACE ... COALESCE 在绝大多数现代 Oracle 实例中不起作用，不是你用错了，而是它根本不该被用于本地管理表空间（LMT）。
为什么 ALTER TABLESPACE COALESCE 总是没反应
你执行 ALTER TABLESPACE users COALESCE 后查 DBA_FREE_SPACE，行数、BLOCK_ID 分布、最大空闲块尺寸几乎不变——这不是操作失败，而是命令被静默忽略或直接报 ORA-1145。原因很直接：
- Oracle 10g 起默认建的都是本地管理表空间（
EXTENT_MANAGEMENT = LOCAL），而COALESCE只对已淘汰的字典管理表空间（DICTIONARY）有效 - LMT 使用位图管理空闲 extent，本身不维护“逻辑上相邻但未登记为连续”的状态，所以无需也无从“合并”
- 即使表空间里全是 64KB 的碎块，
COALESCE也不会把它们拼成一个 1MB 块 - 在 12c/19c/21c 中，对 LMT 执行该语句通常返回
ORA-1145: database must be open for COALESCE（哪怕数据库明明是 open 状态）
怎么确认你是不是在白忙活
别猜，直接查数据字典：
- 运行
SELECT TABLESPACE_NAME, EXTENT_MANAGEMENT, SEGMENT_SPACE_MANAGEMENT FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = 'YOUR_TS' - 如果
EXTENT_MANAGEMENT是LOCAL，那COALESCE就不该出现在你的操作清单里 - 再查
DBA_FREE_SPACE：同一FILE_ID下，BLOCK_ID是否存在首尾相接的情况（比如一条记录BLOCK_ID=1000, BLOCKS=128，下一条BLOCK_ID=1128, BLOCKS=64）？没有这种物理连续性，COALESCE就什么也做不了
真正能合并碎片的操作不是表空间级，而是段级
表空间“满”但分配不出新 extent，问题不在表空间头，而在内部段的高水位线（HWM）卡死、空闲块散落且无法重用。必须下沉到对象层面处理：
- 对普通表：先
ALTER TABLE t ENABLE ROW MOVEMENT，再ALTER TABLE t SHRINK SPACE CASCADE（会下调 HWM、重用空闲块、重建索引） - 含 LOB 列：若为 SECUREFILE，需额外跑
ALTER TABLE t MODIFY LOB (col) (SHRINK SPACE)；BASICFILE 则只能MOVE+REBUILD - 索引碎片：用
ALTER INDEX i REBUILD ONLINE，比COALESCE有效十倍 - 收缩后务必
DBMS_STATS.GATHER_TABLE_STATS，否则优化器仍按旧BLOCKS值估算，可能选错执行计划
Segment Advisor 不是摆设，但它不推荐 COALESCE
Oracle 自带的 Segment Advisor（尤其 10g 起的自动版本）会扫描段并建议哪些适合 SHRINK，但它从不会建议你去执行 ALTER TABLESPACE ... COALESCE。因为它的底层逻辑清楚知道：LMT 下的“碎片”本质是段内空闲块分布问题，不是表空间元数据登记错误。如果你看到 DBA_ADVISOR_FINDINGS 里有 “reclaim space” 类建议，对应动作一定是 SHRINK 或 MOVE，而不是 COALESCE。
最常被忽略的一点：很多人反复执行 COALESCE 并观察 DBA_FREE_SPACE 行数是否减少，这完全是在验证一个本就不该成立的前提。真正的诊断起点，永远是 SELECT * FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'X' ORDER BY BLOCKS DESC —— 先揪出吃空间的大户，再决定 shrink 还是 move。
