占，但不是“删完就释放”；drop table后原段仍以bin$开头保留在表空间中，dba_segments查不到原名不等于空间已释放，需用select tablespace_name,sum(bytes) from dba_segments where segment_name like 'bin$%' group by tablespace_name统计真实占用。
回收站对象到底占不占空间？
占，但不是“删完就释放”。DROP TABLE 后，原表段（包括索引、LOB）物理上仍存在，只是名字被重写成 BIN$xxx 形式，继续计入对应表空间的已用空间。DBA_SEGMENTS 查不到原名 ≠ 空间已空——这是最常踩的误判点。
怎么查回收站真实占用？
必须绕过对象名过滤，直接按命名特征扫描段：
- 执行
SELECT tablespace_name, SUM(bytes) FROM dba_segments WHERE segment_name LIKE 'BIN$%' GROUP BY tablespace_name; - 注意：该语句只统计
BIN$开头的段，不含RECYCLEBIN视图里可能存在的其他格式（如 12c+ PDB 中的BB$前缀），如有跨版本环境需额外补查 - 若结果为空，但表空间仍紧张，说明回收站未启用（查
SHOW PARAMETER recyclebin，值应为ON）或对象已被自动清理
为什么 DBA_RECYCLEBIN 里的记录和空间对不上？
DBA_RECYCLEBIN 是逻辑视图，展示的是“可恢复对象元数据”，而空间占用取决于底层物理段是否还存在。常见脱节原因：
- 对象已被空间压力触发自动清理（
recyclebin参数虽为ON，但 Oracle 在表空间不足时会主动 purge 部分 BIN$ 段） - 执行了
PURGE TABLE xxx或PURGE RECYCLEBIN，但部分对象因依赖关系（如外键约束残留）或锁冲突（ORA-38301）跳过，未报错也未释放 - 多租户环境下，
DBA_RECYCLEBIN默认只显示当前容器（CDB$ROOT 或当前 PDB），而 BIN$ 段可能分布在其他 PDB 的表空间中
查完空间还不释放？盯紧这三处
执行 PURGE DBA_RECYCLEBIN 后 DBA_FREE_SPACE 没变，不是命令失败，而是释放路径没走完：
- 检查是否真清空了：
SELECT COUNT(*) FROM dba_recyclebin;必须返回 0；非零值说明有残留（权限不足、状态异常） - 确认段级释放：再次运行
SELECT tablespace_name, SUM(bytes) FROM dba_segments WHERE segment_name LIKE 'BIN$%' GROUP BY tablespace_name;，结果应全为空 - 留意高水位线（HWM）：即使 BIN$ 段删除，原表空间文件的 HWM 不会自动下降，
DBA_FREE_SPACE显示的“空闲”是 HWM 下的空块，HWM 上方的空间仍被文件占据——要收缩文件得用ALTER DATABASE DATAFILE ... RESIZE，但前提是上方真没段了
dba_segments 的命名特征；清空间必须验证段级消失，而非仅看回收站视图是否为空。
