Oracle回收站使DROP TABLE变为软删除，表被重命名为BIN$格式并保留在原表空间中，占用空间不释放；需执行PURGE操作（如PURGE RECYCLEBIN）才能真正释放段空间。
因为 drop table 默认把表放进回收站（recycle bin），不是物理删除，所以空间不释放。
回收站机制让 DROP 变成“软删除”
Oracle 11g 默认开启 recyclebin，执行 DROP TABLE test 实际只是重命名并移入 user_recyclebin，段（segment）依然占用数据文件里的空间。你查 dba_segments 还能看到它，只是名字变成 BIN$xxx 格式。
- 回收站内容可被
FLASHBACK TABLE恢复，这是设计目的 - 空间真正释放要等显式清理：用
PURGE操作 - DBA 可查所有用户的回收站：
SELECT * FROM dba_recyclebin
怎么确认是不是回收站占着空间？
运行这两条语句对比：
SELECT segment_name, bytes/1024/1024 AS mb FROM dba_segments WHERE owner = 'YOUR_SCHEMA' AND segment_name = 'TEST';
如果查不到，再查回收站：
SELECT original_name, object_name, space*8/1024 AS mb FROM user_recyclebin WHERE original_name = 'TEST';
- 若第二条有结果，说明表还在回收站里，
space字段就是它占的 MB 数 - 注意：
space是以数据库块为单位存的，乘 8KB 才是近似字节数（假设标准块大小）
释放空间的三种 PURGE 方式
根据范围选一种执行即可，执行后对应段立即从数据文件中清除：
- 清空当前用户回收站：
PURGE RECYCLEBIN - 清空某张表（已知原名）：
PURGE TABLE test - 清空整个数据库回收站（需 DBA 权限）：
PURGE DBA_RECYCLEBIN
如果想从一开始就跳过回收站，加 PURGE 后缀：DROP TABLE test PURGE —— 这样删完就真没了，也不会进回收站。
容易忽略的边界情况
即使执行了 PURGE，dba_free_space 显示的空闲空间也可能没立刻变多。这是因为：
- 高水位线（HWM）以下的空间未必能被新对象立即复用，尤其当段是本地管理且使用 AUTOALLOCATE 方式时
- 如果该表空间启用了自动段空间管理（ASSM），碎片可能影响后续分配效率
- 某些情况下需配合
ALTER TABLESPACE ... COALESCE合并相邻空闲区间（仅对字典管理表空间有效）
真正判断空间是否可用，不要只看 dba_free_space 总和，而要看后续建表或插入是否报 ORA-01653 或 ORA-01658 —— 那才是硬指标。
