占，但不是“一直占”；回收站对象的物理段仍占用原表空间，段名重命名为BIN$开头，需用PURGE命令或空间压力触发才释放，DBA_SEGMENTS查不到原名不等于空间已释放。
回收站对象真占表空间吗？
占，但不是“一直占”。oracle 回收站（recyclebin）里的对象，物理段（如 segment）默认仍保留在原表空间中，不会自动释放空间——哪怕你执行了 drop table。只有显式清空或被空间压力触发自动清理时，段才真正删除。
常见误判：DBA_SEGMENTS 里查不到回收站表名 → 就以为空间已释放。错。回收站对象的段名被重命名（如 BIN$abc123$0），仍计入对应表空间的已用空间。
- 查真实占用：用
SELECT tablespace_name, SUM(bytes) FROM dba_segments WHERE segment_name LIKE 'BIN$%' GROUP BY tablespace_name; - 确认是否启用回收站：
SHOW PARAMETER recyclebin，值必须是ON（默认 10g+ 是 ON） - 注意：
FLASHBACK DROP可恢复的对象，一定还在回收站且占空间；已执行PURGE或被自动清理的，才不占
为什么 PURGE DBA_RECYCLEBIN 有时没效果？
不是命令失效，而是权限、作用域或对象状态卡住了。
- 必须用有
SYSDBA权限的用户执行（如sys），普通用户即使有DBA角色也不行 ——PURGE DBA_RECYCLEBIN是系统级操作 - 如果回收站里有跨 PDB 的对象（多租户环境），当前容器（CDB$ROOT）下执行只清本容器，需切到对应 PDB 再执行
- 某些对象处于“不可清除”状态：比如被其他会话正在查询（
ORA-38301: can not perform DDL/DML over object in Recycle Bin），或依赖对象（如索引、约束）未被一并标记为可删 - 执行后无报错≠全部清完：部分对象可能因权限或状态跳过，建议执行后立刻查
DBA_RECYCLEBIN确认是否为空
PURGE 命令的三种写法和适用场景
别只记 PURGE DBA_RECYCLEBIN。不同场景该用哪个，直接决定能不能清掉、会不会误伤。
-
PURGE RECYCLEBIN：清当前用户自己的回收站，安全，日常够用；普通用户也能执行 -
PURGE DBA_RECYCLEBIN：清整个数据库所有回收站，必须SYSDBA；适合 DBA 快速释放空间，但高并发时可能阻塞其他会话（因为要获取全局锁） -
PURGE TABLESPACE ts_name：只清指定表空间下的回收站对象，不影响其他表空间；适合空间紧张但不想全库清理时用，也支持加USER user_name限定用户
示例：PURGE TABLESPACE USERS USER scott; —— 只清 USERS 表空间里 scott 用户的回收站对象，精准且低风险。
清完空间还不释放？检查这三处
执行 PURGE DBA_RECYCLEBIN 后 DBA_FREE_SPACE 没变，不是命令失败，而是空间还没“归还”给操作系统或分配给新对象。
- 表空间是
ASSM（自动段空间管理）？那空间释放后会先进入本地管理位图（LMT），不会立刻反映在DBA_FREE_SPACE的块数上；查DBA_TABLESPACE_USAGE_METRICS更准 - 数据文件没开启
AUTOEXTEND？空间虽已空闲，但文件大小不变，df -h看不到磁盘释放；需手动ALTER DATABASE DATAFILE ... RESIZE才能缩文件 - 存在延迟清理：Oracle 12c+ 中，若启用了
INMEMORY或某些高级压缩特性，段删除后元数据清理可能延迟几秒到几分钟，DBA_SEGMENTS里还能短暂看到BIN$段
最常被忽略的一点：回收站清完了，但表空间里还有别的大对象（比如没删的临时 LOB、未提交的全局临时表数据），别让 PURGE 背锅。
