19c中SHRINK SPACE不默认启用，须先执行ALTER TABLE ... ENABLE ROW MOVEMENT；仅对堆表有效，大表需加CASCADE才能收缩关联索引并降低HWM。
能用，但必须分两步走，且大表上不加 CASCADE 很可能白忙活。
Shrink Space 在 19c 中是否默认可用？
不是默认开启的。执行前必须先启用行移动：ALTER TABLE table_name ENABLE ROW MOVEMENT。否则会报错 ORA-10636: row movement is not enabled。19c 虽然支持在线 shrink，但这个前提条件没变——它不是“开箱即用”，而是“开箱即配”。另外，SHRINK SPACE 只对堆表（heap table）有效，索引组织表（IOT）、外部表、临时表等不支持。
为什么大表必须用 SHRINK SPACE CASCADE？
单独执行 ALTER TABLE t SHRINK SPACE 只处理表段本身，不会触碰关联的索引段。大表通常带多个索引，这些索引的高水位线依然卡在高位，后续查询仍会扫大量空块。常见现象是：表段空间降了，但 DBA_SEGMENTS 里索引大小没变，全表扫描或索引范围扫描性能无改善。所以对大表，应优先用：
-
ALTER TABLE t SHRINK SPACE CASCADE：自动 shrink 所有相关索引（含主键、唯一/非唯一索引） - 若需控制节奏，可拆成两步：
SHRINK SPACE COMPACT（仅重组数据，不降 HWM，允许并发 DML）+ 后续SHRINK SPACE CASCADE（真正降 HWM，需短暂锁表）
执行时容易被忽略的三个硬性限制
19c 中 SHRINK SPACE 不是万能的，以下情况会直接失败：
- 表上有
DISABLED状态的约束（哪怕未启用，只要存在定义），会报ORA-10637；需先ENABLE或DROP再操作 - 表被任何会话以
FOR UPDATE持有行锁，或正在执行 DDL（如建索引），SHRINK会阻塞甚至超时 - 表所在表空间为
SMALLFILE且启用了AUTOEXTEND，shrink 后可能触发文件自动扩展又立刻收缩，反复抖动；建议提前检查DBA_DATA_FILES的AUTOEXTEND设置
如何验证 shrink 是否真正生效？
别只看 NUM_ROWS 或 AVG_ROW_LEN，它们和 HWM 无关。关键查两个视图：
-
SELECT blocks, empty_blocks FROM user_tables WHERE table_name = 'T'：blocks下降才说明 HWM 降低；empty_blocks增加只是碎片化表现，不等于空间释放 -
SELECT bytes/1024/1024 FROM dba_segments WHERE segment_name = 'T' AND segment_type = 'TABLE'：这才是真实占用空间，对比 shrink 前后值
注意：ANALYZE TABLE ... COMPUTE STATISTICS 已过时，19c 必须用 DBMS_STATS.GATHER_TABLE_STATS 更新统计信息，否则执行计划可能继续走旧路径。
大表 shrink 最耗神的不是命令本身，而是评估依赖关系——索引、物化视图日志、外键引用、审计策略都可能暗中挡路。一次 shrink 失败，八成不是语法错，而是某个隐藏对象没清理干净。
