Oracle 11g中DROP TABLE后表空间空间未立即增加，是因为回收站启用导致软删除：表被重命名为BIN$格式保留在原表空间，段仍占用空间；需执行PURGE操作（如PURGE RECYCLEBIN）才能真正释放。
DROP TABLE 后表空间没释放，不是 bug，是 Oracle 默认启用回收站（recyclebin）导致的软删除行为。表被重命名成 BIN$xxx$0 格式，段（segment）仍留在原表空间里，空间自然不还。
怎么确认是不是回收站占着空间？
别只看 dba_free_space，先查表是否存在，再查回收站：
- 查原表段：
SELECT segment_name, bytes/1024/1024 AS mb FROM dba_segments WHERE owner = 'YOUR_SCHEMA' AND segment_name = 'YOUR_TABLE';—— 若无结果，说明已“消失” - 查回收站：
SELECT original_name, object_name, space*8/1024 AS mb FROM user_recyclebin WHERE original_name = 'YOUR_TABLE';—— 若有记录，space字段就是它占的 MB 数（按 8KB 块大小估算）
PURGE 的三种用法和适用场景
执行任意一种即可真正释放段空间，但权限和范围不同：
-
PURGE RECYCLEBIN：清空当前用户回收站，最常用，无需 DBA 权限 -
PURGE TABLE your_table：只清掉某张原名的表（哪怕它在回收站里有多个版本），精准控制 -
PURGE DBA_RECYCLEBIN：DBA 清全库回收站，慎用，可能误删他人对象
想跳过回收站直接物理删？加 PURGE 后缀：DROP TABLE your_table PURGE —— 这样一执行就真没了，不进回收站。
为什么 PURGE 了，dba_free_space 还是没变多？
这是常见误解。空间释放 ≠ 立即反映在空闲块统计中：
- HWM（高水位线）以下的空闲块，Oracle 可能暂不纳入
dba_free_space统计，尤其在 ASSM（自动段空间管理）表空间中 - 真正判断空间是否可用，得看后续建表或插入会不会报
ORA-01653或ORA-01658 - 如果数据文件末尾有连续空闲区，可手动收缩：
ALTER DATABASE DATAFILE '/path/to/file.dbf' RESIZE 500M;，但注意会报ORA-03297（文件含超出 resize 范围的数据），需先确认空闲区位置
容易忽略的细节
回收站对象不只是表，索引、触发器、LOB 段等也一起进去；PURGE TABLE 不会自动清理关联索引，它们仍以 BIN$ 形式存在，得单独 PURGE INDEX 或用 PURGE RECYCLEBIN 一并处理。另外，FLASHBACK TABLE 只能恢复未被 PURGE 的对象，一旦 PURGE 就不可逆——这点在生产环境执行前必须对齐操作意图。
