上个月收到一套Oracle生产库的磁盘告警，oradata目录使用率达到了98%。登录服务器简单查了一下，一个应用表空间分配了800GB，实际数据只有120GB左右。按正常思路，这种情况直接收缩表空间、把空闲空间还给操作系统就行。结果我连续执行了三条常规回收SQL，全部失败，报了一堆让人摸不着头脑的错误码。这篇就把这次空间无法回收的排查过程拆开讲清楚，从原因到诊断再到最终落地，都是一线实操的经验，同行应该用得上。
先说结论性的一件事：Oracle的“空间回收”和大多数人理解的“删了数据就释放空间”完全是两码事。很多DBA在运维中都会遇到类似情况——表空间明明有很大一部分“空着”，却无论如何都收不回来。这里面既有数据库原理层面的限制，也有段对象自身的结构依赖和锁问题。我会用实际的操作过程和报错案例，把“无法回收”这个结果背后的真正原因一层层剥开。
1. 空间无法回收的核心原因剖析
遇到空间无法回收的时候，先别急着怀疑Oracle出了bug或者表空间损坏，绝大多数情况都逃不开下面这几类原因。弄清楚原理，后面的诊断和操作才有方向。
1.1 高水位线：删了不等于还了空间
这是所有空间回收问题里最经典、最容易被忽略的原因。Oracle表空间中的数据文件，逻辑上被切成一个一个小块，段对象在分配给它的这些块里不断插入数据。高水位线（High Water Mark)指的就是段中曾经使用过的最高块号。你DELETE掉一千万行，Oracle只是把块标记为空闲，但段的高水位线不会自动降下来。下一次INSERT的时候，Oracle还是会优先使用高水位线以上的新块，而不是高水位线以下那些空出来的块。
我用一个生活类比来解释一下：泳池放了半池水，但池壁上曾经浸湿的水痕一直都在。Oracle判断这个段有多少数据量，看的不是当前水面上还有多少水，而是水痕的位置。所以就算你把数据删光，段占用的物理空间还是那么大。表现在表空间层面，就是dba_free_space里明明有大量空闲空间，数据文件本身却一点没变小。
SHRINK操作之所以能释放空间，原理就是移动行的物理位置，把高水位线以下的那些空块压缩并释放出来。但正因为行要发生物理移动，ROWID会变，Oracle默认不允许。这也是后面很多报错的根源所在。
1.2 段管理和存储参数的限制
不是所有的表空间都支持在线收缩。Oracle从9i开始引入自动段空间管理（ASSM），用位图来管理段内的空间状态，10g之后普通表空间默认都是ASSM。SHRINK这种在线压缩操作，要求表空间必须采用ASSM。如果你遇到的是早期迁移过来的手动段空间管理（MSSM）表空间，SHRINK直接就会报ORA-10635，根本没有商量余地。
存储参数方面，PCTFREE和MAXEXTENTS同样会影响收缩结果。PCTFREE如果设置过大，块内预留空间太多，收缩时移动行的空间估算就会出问题；MAXEXTENTS过小，收缩过程中Oracle需要为段分配临时扩展块来整理数据，扩展不动也会直接失败。很多人只盯着高水位线，忽略了这两个参数，结果脚本在测试库跑得顺顺当当，生产库一执行就报ORA-01653或ORA-01654，这类报错往往不是空间不够，而是MAXEXTENTS触顶了。
1.3 对象依赖与锁：一个索引就能锁死全局
SHRINK不是只移动表的行，索引行也要同步维护，所以可级联收缩CASCADE会同时处理该表上的索引。麻烦就麻烦在这个“同时处理”上：一旦表上有函数索引、全局分区索引或者物化视图日志，收缩过程中要做的事情会成倍增加，任何一个依赖对象状态异常，收缩事务就会整体回滚。
生产环境里最常见的其实是锁冲突。SHRINK本质上要改数据行的物理位置，为避免DML操作把行地址搞乱，Oracle在收缩期间必须拿住表级别的DML锁，甚至DDL锁。这时候如果有一个长达数小时的报表事务正在读取这张表的数据，SHRINK操作就会一直卡在等待队列里，直到超时或被监控脚本直接Kill掉。我见过不少“无法回收”案例，排查到最后不是技术问题，而是业务高峰期撞上了一张长期未提交的事务。
2. 动手之前：用诊断思路快速定位问题
遇到无法回收的情况，最忌讳的就是上来就执行一条SHRINK期望一步到位。我总结了一套从宏观到微观、从参数到对象的排查路径，照着走，基本十分钟内就能把根因锁定。
2.1 看清家底：一条SQL理清表空间使用情况
第一步是确认表空间在Oracle内部到底是个什么状态。执行下面这条SQL，可以同时看到总大小、当前空闲空间和使用率：
SELECT df.tablespace_name, ROUND(SUM(df.bytes)/1024/1024/1024, 2) AS total_gb, ROUND(NVL(SUM(fs.free), 0)/1024/1024/1024, 2) AS free_gb, ROUND((1 - NVL(SUM(fs.free), 0)/SUM(df.bytes)) * 100, 1) AS used_pct FROM dba_data_files df LEFT JOIN ( SELECT tablespace_name, file_id, SUM(bytes) AS free FROM dba_free_space GROUP BY tablespace_name, file_id ) fs ON df.file_id = fs.file_id AND df.tablespace_name = fs.tablespace_name GROUP BY df.tablespace_name ORDER BY total_gb DESC;这里有一个非常关键的概念需要区分：dba_free_space统计的是表空间内部所有空闲区间的总和，而操作系统上数据文件的大小才是真正占磁盘的东西。如果表空间内部空闲空间很大，但数据文件大小纹丝不动，说明空闲空间集中在高水位线以下，属于“够用但是拿不出来”的状态，这就是典型的HWM问题。如果表空间内部本身没有多少空闲空间，但数据文件极大，则说明段对象分配了大量空间但没人用，需要进入第二步定位段对象。
2.2 层层下钻：从表空间到段对象
确认了目标表空间之后，按段大小排序找出T0P20的对象：
SELECT * FROM ( SELECT owner, segment_name, segment_type, ROUND(bytes/1024/1024, 2) AS size_mb, extents, blocks FROM dba_segments WHERE tablespace_name = 'TBS_APP' ORDER BY bytes DESC ) WHERE ROWNUM <= 20;通过这条SQL，你能快速锁定那些真正占用空间的表、索引或者回滚段。常见情况是TOP3的对象占掉了整个表空间八成的空间，而这些对象的数据行数却不多。这时候用DBMS_SPACE.SPACE_USAGE这个包看段内部的实际分配情况会更直观：
SET SERVEROUTPUT ON DECLARE v_unformatted_blocks NUMBER; v_unformatted_bytes NUMBER; v_fs1_blocks NUMBER; v_fs1_bytes NUMBER; v_fs2_blocks NUMBER; v_fs2_bytes NUMBER; v_fs3_blocks NUMBER; v_fs3_bytes NUMBER; v_fs4_blocks NUMBER; v_fs4_bytes NUMBER; v_full_blocks NUMBER; v_full_bytes NUMBER; BEGIN DBMS_SPACE.SPACE_USAGE('APP', 'T_ORDER_HIS', 'TABLE', v_unformatted_blocks, v_unformatted_bytes, v_fs1_blocks, v_fs1_bytes, v_fs2_blocks, v_fs2_bytes, v_fs3_blocks, v_fs3_bytes, v_fs4_blocks, v_fs4_bytes, v_full_blocks, v_full_bytes); DBMS_OUTPUT.PUT_LINE('unformatted=' || v_unformatted_blocks || ' fs1=' || v_fs1_blocks || ' fs2=' || v_fs2_blocks || ' fs3=' || v_fs3_blocks || ' fs4=' || v_fs4_blocks || ' full=' || v_full_blocks); END; /这个包会输出段空间中不同状态的比例：fs1到fs4表示块内空闲空间从少到多的块数，full是满块数，unformatted是已经分配但还没格式化使用的块数。如果看到fs2、fs3、fs4占了绝大多数，而这个段的总行数又不多，那基本就能确认是碎片化和高水位线问题，SHRINK这个方向是对的。
2.3 判断可收缩性：哪些情况能收，哪些不能收
在真正执行任何SHRINK命令之前，先从系统表里确认三个条件：
-- 表空间是否使用ASSM SELECT tablespace_name, segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'TBS_APP'; -- 表是否已开启ROW MOVEMENT SELECT owner, table_name, row_movement FROM dba_tables WHERE owner = 'APP' AND table_name = 'T_ORDER_HIS'; -- 是否存在大量回收站对象占空间 SELECT owner, object_name, type, space FROM dba_recyclebin WHERE space > 100;这三个检查缺一不可。表空间不是ASSM，SHRINK直接免谈；表没开启ROW MOVEMENT，单独对表做SHRINK会报错；回收站里面有大量DROP掉的对象，这些空间也不是普通SHRINK能直接释放的，需要先PURGE。这里顺便提醒一下，平时养成定期清回收站的习惯，别让那些被误删对象的尸体占用宝贵空间。
3. 实操案例：Oracle空间回收从报错到落地
讲完原理和诊断思路，接下来用一个完整的生产案例复盘，展示从第一次报错到最终把空间收回来的整个过程。这套流程不是我凭空生成的，是把三类频率最高的生产故障汇总成的一个代表性场景，你对照自己的环境稍作调整就能用。
3.1 现场还原：一个真实的表空间收缩故障
环境是Oracle 19c，应用表空间TBS_DATA分配了800GB，业务高峰期磁盘使用率98%。通过2.1节的SQL查询发现，dba_free_space里的空闲空间只有10GB左右，说明这800GB空间的绝大部分都已经被段对象占用了，可实际业务数据只有120GB左右。也就是说，段对象吞掉了大量空间，但对业务毫无贡献。
第一次尝试按文档执行在线表空间收缩：
ALTER TABLESPACE TBS_DATA SHRINK SPACE KEEP 300G;结果Oracle直接抛了ORA-10635：Invalid segment or tablespace。这个错误码的含义是目标段对象或表空间不支持在线收缩。遇到这个报错，很多人第一反应是检查表空间参数，但实际表空间确实是ASSM，参数没问题。真正的问题出在后面那两个大表上，它们的ROW MOVEMENT都是DISABLED状态，表空间级SHRINK一旦需要移动这些段对象，Oracle会立即拒绝。
3.2 诊断过程：不要被报错牵着走
这个时候如果只盯着ORA-10635的语义去翻MOS，大概率会绕很久。正确的做法是回到对象层面，把问题拆到最小粒度再执行。我先通过2.2节的段大小查询，锁定了三个核心对象：
- APP.T_ORDER_HIS，历史订单表，段大小390GB，实际数据行数约1800万行；
- APP.T_FLOW_LOG，流程日志表，段大小280GB，实际数据行数约2200万行；
- APP.IDX_T_ORDER_TIME，前一张表上的复合索引，段大小120GB。
这三张段对象加起来就有790GB左右，基本解释了为什么现在找不到可见的空闲空间。下一步用DBMS_SPACE.SPACE_USAGE查看T_ORDER_HIS内部状态，结果fs2加fs3加fs4占了85%以上，full块不到5%。这说明该表的大量块都是半满甚至几乎全空的，数据分布严重碎片化。
在跑任何SHRINK之前，我还查了一下V$LOCKED_OBJECT是否有长事务锁着这些表，结果一到下班时间点，就有一张报表正在扫T_FLOW_LOG的数据，为时3小时。这里多说一句，日常运维中，空间回收前先摸清楚对象上的活动会话非常重要，否则收缩动作会被锁直接拖死，白等半小时后TIMEOUT回到“无法回收”的谜题里。
3.3 解决方案落地：一步一步把空间收回来
确认业务低峰时段里没有任何长事务会话后，我按下面的顺序执行了完整的回收方案：
第一步，给目标表开启ROW MOVEMENT：
ALTER TABLE APP.T_ORDER_HIS ENABLE ROW MOVEMENT; ALTER TABLE APP.T_FLOW_LOG ENABLE ROW MOVEMENT; ALTER TABLE APP.T_INDEX_TEST ENABLE ROW MOVEMENT;这里不用慌张，ROW MOVEMENT只是允许行在物理块之间搬迁，并不会立刻动数据。它本质上是给SHRINK操作一个许可，操作完成后可以再DISABLE掉。
第二步，对目标表执行级联收缩，一次处理一张表：
ALTER TABLE APP.T_ORDER_HIS SHRINK SPACE CASCADE;这一步会同时压缩T_ORDER_HIS表的段、索引以及LOB段（如果存在）。执行过程中监控一下生成的归档日志量和会话等待事件。如果等待事件长时间停留在“enq: TX - row lock contention”，说明还是有隐蔽的并发事务在占用这张表，宁可停掉收缩保业务，也不要强行执行下去，以免触发大面积的行迁移锁。
T_ORDER_HIS收缩完成后，段大小从390GB降到了约95GB，效果立竿见影。紧接着用同样的命令处理T_FLOW_LOG，这个表稍微特殊一些，它上面有物化视图日志，CASCADE模式直接把物化视图日志一起处理掉了，并没有报错。不过如果你的环境里有复杂的物化视图刷新场景，建议先检查JOBS是否正在刷新，否则收缩和刷新同时跑，会产生资源竞争。
第三步，再次执行表空间级的在线收缩：
ALTER TABLESPACE TBS_DATA SHRINK SPACE KEEP 300G;这次没有再报ORA-10635，Oracle开始真正移动高水位线以上的空闲扩容块。收缩过程耗时约二十分钟，期间表空间短暂处于只读状态，因为必须保证数据一致。完成后，表空间的大小降到350GB，但KEEP参数指定的300G只是一个期望值，实际文件大小不能小于段实际占用的空间，这个参数更多是一个下限保护。
最后用df -h查看，磁盘使用率从98%降到了73%，空间回收闭环完成。
3.4 备选方案：脏路径上的数据泵导出导入
如果你的情况比上面这个更极端，比如尝试SHRINK时发现表结构里有太多函数索引、全局分区索引，或者表空间本身就是MSSM时代的老古董，SHRINK这条路根本走不通，不用硬扛。可以用数据泵（Data Pump）导入导出来清理空间，思路是把数据搬到一个全新的表空间：
-- 原库导出 expdp APP/APP_DIR dumpfile=exp_tbs.dmp logfile=exp_tbs.log tables=T_ORDER_HIS -- 新库导入到TBS_DATA_NEW impdp APP/APP_DIR dumpfile=exp_tbs.dmp logfile=imp_tbs.log table_exists_action=replace remap_tablespace=TBS_DATA:TBS_DATA_NEW这条路唯一的硬伤是时间窗口比较长，而且需要额外准备一块临时磁盘和一套导入导出目录。不过它有SHRINK无法替代的优势：重建后的表物理结构干净，高水位线完全归零，索引重建也更紧凑。我一般在老系统升级或者大版本迁移时用这套方案，平时生产环境的小规模收缩还是优先SHRINK。
4. 常见问题与避坑指南
4.1 高频报错速查表
这里整理一份我在各类空间回收场景中遇到的报错及处理方法，直接对照查就行。
| 报错代码 | 含义 | 处理思路 |
|---|---|---|
| ORA-10635 | 无效段或表空间，不支持收缩 | 检查表空间是否ASSM、段是否启用ROW MOVEMENT |
| ORA-03297 | 数据文件中包含超范围的数据，无法收缩 | 数据文件尾部有段对象，先移动段或者对象级SHRINK后再试 |
| ORA-01653 | 无法扩展表段 | 表空间剩余空间不足或MAXEXTENTS触顶，调整存储参数或扩大表空间 |
| ORA-01654 | 无法扩展索引段 | 先查索引所在表空间剩余空间，回收站清理后再收缩 |
| ORA-14438 | 分区键更新操作不允许 | SHRINK过程触碰分区约束，检查分区表结构和触发器 |
| ORA-00060 | 死锁 | 收缩操作与其他DML形成了循环等待，定位锁持有者并协调业务 |
| ORA-30036 | UNDO空间不足 | 收缩期间生成的UNDO量过大，增大UNDO表空间或者分批收缩 |
这个表格里的坑我都踩过，重点提示一下ORA-03297，这类报错容易被人误解成“表空间没有足够的剩余空间”，其实真正含义是你的数据文件末尾还有数据块，文件缩不进去。遇到这个错误，不要试图直接改数据文件大小，而是要先对文件尾部的段做一次对象级收缩，把数据块挪到文件头部，再回头来缩文件。
4.2 最容易踩的五个坑
第一个坑是直接在业务高峰执行SHRINK。SHRINK期间会在表上拿锁，时间长短取决于数据量和碎片程度，最长可能持续数小时。我见过有人凌晨两点执行收缩操作，结果恰好有跨时区的业务在跑批量任务，锁冲突导致三天后业务方投诉性能下降。操作前一定要结合业务规律确认低峰窗口，不能只看本地时间。
第二个坑是不检查回收站就直接收缩。回收站里DROP掉的表虽然不占业务空间，但当你尝试扩大或收缩表空间时，Oracle会优先考虑回收站对象，导致SHRINK过程中突然冒出ORA-01653。处理办法就是先执行PURGE DBA_RECYCLEBIN，把垃圾清干净再动手。
第三个坑是忽略STATS统计信息。SHRINK会大量移动行，直接导致表和索引的统计信息失效。如果收缩之后没有马上重做统计信息，执行计划很可能会乱跳，跑出几条全表扫描的SQL，业务会明显变慢。这是我吃过的大亏，后来养成了“收缩后必须重统计”的铁律。
第四个坑是大表不应该一次SHRINK到底。一个60GB的大表，一次性收缩到20GB，期间会生成大量UNDO和REDO，对IO和归档日志的压力非常大。正确做法是先确认业务可接受的窗口，必要时分批处理，比如按分区收缩。
第五个坑是忘了处理MAXEXTENTS参数。现在很多系统还是老配置文件，MAXEXTENTS只有几十个，SHRINK过程中段要临时扩展新的块来存放被挪动的行，扩展不了就报错。执行前花一分钟查一下dba_segments的max_extents，值偏小就直接用ALTER TABLE STORAGE（MAXEXTENTS UNLIMITED）预抬一下，避免中途翻车。
4.3 让空间保持健康的日常习惯
把空间回收变成日常运维的一部分，比每次等到磁盘告警再救火要靠谱得多。我自己的习惯是每月固定做一次表空间使用率巡检，重点看段对象增长率和碎片比例。对这个月增长异常的表，提前安排下个月的SHRINK窗口。监控上可以钉住几个关键指标：表空间总大小、空闲率、TOP段对象大小和回收站占用，任何一项超过阈值就自动发告警。
对于业务上只增不减的历史表，比如订单历史表、审计日志表，我更推荐直接建立按月或按季度的分区，配合数据归档策略。分区表在空间管理上有一个天然优势：可以单独TRUNCATE或者DROP一个分区，瞬间把整个分区的空间释放给操作系统，不需要经历SHRINK那种逐行移动的过程。这和表级别的DELETE方式完全不是一个量级。
另外提醒一句，如果生产环境用的是Oracle EBS这类业务系统，WIP工单、历史流水这类表往往数据量极大且更新频繁，收缩频率不宜过高。只要空间能维持在两到三个月内有富余，尽量不要频繁去动大表。频繁的物理行移动只会不断加剧索引碎片化，最后反而让业务查询性能变差。
这次案例之后，我个人的体会是：Oracle空间回收的难点从来不在命令本身，而在于操作前有没有把对象的物理结构、锁竞争和存储参数都摸透。遇到无法回收的报错，先停一下，回到原理层面对照检查一遍原因，再走SHRINK这条路，你会比我当时少走很多弯路。最后分享一个存在脚本里的习惯动作：所有空间回收操作前，先SELECT COUNT(*) FROM V$LOCKED_OBJECT确认锁状态，再SELECT SUM(BYTES) FROM DBA_RECYCLEBIN确认回收站占用，这两步加起来不过半分钟，却能挡掉绝大多数收缩失败。
