ora-10635报错是因不满足三项硬性前提：表空间必须为assm（auto）、对象必须为堆组织表且不含long列或fda、lob段需compression=none且securefile=no。
SHRINK SPACE 失败不是随机的，而是 Oracle 在执行前做了几道硬性检查，任一不满足就直接拒绝——它不会告诉你具体哪条没过，只抛一个笼统错误。
ORA-10635：表空间或对象类型不合规
这是最常被误判为“权限不足”或“空间不够”的错误，实际和这两者完全无关。必须同时满足三项：
-
SELECT segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS'必须返回AUTO；MANUAL表空间哪怕空着也绝对不行 - 目标必须是堆组织表（
HEAP TABLE），IOT、临时表、物化视图日志表、簇表都不支持 - 表不能含
LONG列，也不能启用Flashback Data Archive；哪怕LONG列全为空，Oracle 也直接拒 shrink
LOB 字段还有额外限制：SELECT compression, securefile FROM dba_lobs 中 compression 必须为 NONE、securefile 必须为 NO，否则同样触发 ORA-10635。
ORA-08102：索引与数据不一致
这个错误说明底层索引键丢失或损坏，常见于以下场景：
- 在
SHRINK SPACE前未执行ALTER TABLE t ENABLE ROW MOVEMENT，命令看似成功但实际没生效，后续 shrink 会因行位置错乱触发校验失败 - 表上有函数索引或位图连接索引，Oracle 内部不支持 shrink 这类索引所在的表，但错误码仍显示为 ORA-08102，容易误导
- 执行 shrink 前刚做过
ADD COLUMN ... NOT NULL DEFAULT或大范围DELETE，未及时收集统计信息或存在未提交事务，导致索引元数据滞后
遇到 ORA-08102，先查 v$transaction 确认无活跃事务，再用 ANALYZE TABLE t VALIDATE STRUCTURE CASCADE 检查索引一致性。
ORA-30044：对 UNDO 表空间执行 SHRINK
所有 Oracle 版本（包括 19c、21c）都明确禁止对撤销表空间执行 SHRINK SPACE，报错固定为 ORA-30044: invalid tablespace type for shrink operation。
原因在于 UNDO 数据文件的高水位由最老未过期的撤销记录钉住，不是传统碎片。即使 DBA_FREE_SPACE 显示大量空闲块，也不能收缩。
唯一可行路径是重建：CREATE UNDO TABLESPACE undotbs_new → ALTER SYSTEM SET undo_tablespace = undotbs_new → 等待旧表空间无活动事务 → DROP TABLESPACE undotbs_old INCLUDING CONTENTS AND DATAFILES。
TEMP 表空间 SHRINK SPACE 不生效
Oracle 19c 及以后版本中，ALTER TABLESPACE temp SHRINK SPACE 语法能通过，但实际什么也不做——这不是 bug，是设计如此。因为 TEMP 表空间使用的是临时文件（tempfile），而 SHRINK SPACE 是为永久表空间中的段（segment）设计的。
真实空闲空间要看 v$temp_space_header，不是 DBA_TEMP_FILES。若 free_blocks 接近 0，说明已无可用 extent，此时必须重建 TEMP 表空间才能释放磁盘空间。
别在 19c+ 上浪费时间试 SHRINK SPACE，它永远不生效，且不会报错，只会静默失败。
