Oracle不能批量收缩多个数据段，必须逐表执行ALTER TABLE ... SHRINK SPACE，且每张表须先启用行移动；真正释放操作系统级空间还需ALTER DATABASE DATAFILE ... RESIZE或重建表空间。
直接说结论：Oracle 不能“批量收缩多个数据段”到单条命令里，必须逐个 SHRINK SPACE，且每张表都要先 ENABLE ROW MOVEMENT；真正释放到底层存储（即操作系统文件大小），还得靠 ALTER DATABASE DATAFILE ... RESIZE 或重建表空间。
为什么 SHRINK SPACE 不能批量执行
Oracle 的 SHRINK SPACE 是表级（或分区级）操作，不支持通配符、列表或视图批量触发。DBA 常误以为 ALTER TABLESPACE ... SHRINK SPACE 能批量收整个表空间——但它只对“自动段空间管理（ASSM）+ 本地管理”的表空间中“未被任何对象占用的空闲区”做合并（COALESCE），并不移动或压缩任何已存在段的数据。
-
ALTER TABLESPACE users SHRINK SPACE实际效果 ≈ALTER TABLESPACE users COALESCE，仅整理碎片，不降低任何表的 HWM - 想压缩某张表，必须显式写
ALTER TABLE schema.table_name SHRINK SPACE - 没有类似
SHRINK ALL TABLES IN TABLESPACE users的语法，强行封装脚本也需逐条执行并捕获异常
批量收缩前必须检查的三件事
漏掉任意一项，SHRINK SPACE 会静默跳过或报错失败，但空间一丁点都不会释放。
- 表是否启用了行移动：
SELECT table_name, row_movement FROM dba_tables WHERE tablespace_name = 'USERS'；未启用的必须先跑ALTER TABLE t1 ENABLE ROW MOVEMENT - 是否存在不可收缩对象：IOT 表、带函数索引/域索引的表、LOB 段未指定
INCLUDING DATA的表，都会导致SHRINK失败 - 是否有未提交事务或阻塞锁：
SELECT * FROM v$locked_object WHERE object_id IN (SELECT object_id FROM dba_objects WHERE object_name = 'T1')；锁住的表执行SHRINK SPACE会卡住或报ORA-00054
真正释放到底层存储的关键一步
即使你把所有表都成功 SHRINK SPACE 了，df -h 看数据文件大小依然不变——因为 Oracle 只把 extent 标记为“可重用”，没通知操作系统回收磁盘块。
- 先确认空闲空间已真实增加：
SELECT SUM(bytes)/1024/1024 FROM dba_free_space WHERE tablespace_name = 'USERS' - 再缩小单个数据文件：
ALTER DATABASE DATAFILE '/u01/oradata/db/users01.dbf' RESIZE 8G（目标值不能小于dba_free_space中最大连续空闲块） - 如果文件内碎片严重，
RESIZE会报ORA-03297；此时只能走“新建表空间 → 移表 → 重建索引 → 删除旧表空间”路径
别依赖 Segment Advisor 自动生成收缩语句
虽然 DBMS_ADVISOR 或 OEM 的 Segment Advisor 能列出“建议收缩的段”，但它只输出诊断，不生成可执行 SQL，也不处理依赖关系。更关键的是：它默认只扫描满足“空闲空间 > 10% 且段大小 > 10MB”的对象，小表、刚删完数据还没分析统计信息的表，它根本不会提醒。
生产环境批量收缩，最稳的方式是：先查出大表 + 高碎片表（结合 dba_segments 和 dba_extents），人工确认业务影响，再写循环脚本逐个 ENABLE ROW MOVEMENT + SHRINK SPACE，最后统一 RESIZE。中间任何一步出错，都得回退检查——比如 SHRINK SPACE COMPACT 成功但 SHRINK SPACE 失败，说明 HWM 下仍有不可移动行（如含 LONG 列、或被 IOT 引用）。
