回收站对象确实占用表空间，段名改为BIN$xxx仍驻留原表空间；需用SELECT tablespace_name,SUM(bytes)/1024/1024/1024 AS gb FROM dba_segments WHERE segment_name LIKE 'BIN$%' GROUP BY tablespace_name确认占用，再结合PURGE DBA_RECYCLEBIN（需SYSDBA权限、注意多租户容器及对象阻塞状态）或PURGE TABLE "BIN$xxx"等针对性命令清理。
回收站对象确实会占满表空间，而且不是“暂时占着等你发现”，是实打实地把段留在原表空间里，名字改成 BIN$xxx 而已。直接查 DBA_SEGMENTS 看不到原表名 ≠ 空间已释放，必须用针对性手段清理。
怎么确认回收站真在吃空间？
别信“删了就没了”的直觉。先跑这条 SQL 看回收站段是否霸占空间：
SELECT tablespace_name, SUM(bytes)/1024/1024/1024 AS gb FROM dba_segments WHERE segment_name LIKE 'BIN$%' GROUP BY tablespace_name ORDER BY gb DESC;
如果结果里某表空间的 gb 值很大，说明回收站就是元凶。再查 DBA_RECYCLEBIN 确认对象数量和类型（表、索引、约束等），尤其注意 ORIGINAL_NAME 和 OBJECT_NAME（后者才是真实段名，带 BIN$ 前缀）。
PURGE DBA_RECYCLEBIN 为什么没效果？
常见失败不是命令写错，而是卡在权限、容器或对象状态上：
- 必须用
SYS或有SYSDBA权限的用户执行；SELECT * FROM SESSION_ROLES;查不到DBA就别硬试，会报ORA-01031 - 多租户环境下，默认在
CDB$ROOT执行会清掉所有 PDB 的回收站；要精准清理某个 PDB，得先ALTER SESSION SET CONTAINER = pdb_name; - 对象被其他会话正在查询或锁住时，会报
ORA-38301: can not perform DDL/DML over object in Recycle Bin；查V$SESSION和V$LOCK找出阻塞会话，必要时ALTER SYSTEM KILL SESSION - 执行后无报错≠全清完；立刻再查
DBA_RECYCLEBIN，若还有记录，说明部分对象跳过了
该用哪个 PURGE 命令？别一上来就全库清
不同场景对应不同命令，选错可能误伤或无效：
-
PURGE RECYCLEBIN：只清当前用户自己的回收站，安全，普通用户也能跑 -
PURGE TABLESPACE users USER scott：只清USERS表空间里scott用户的对象，精准低风险，适合局部空间告急 -
PURGE DBA_RECYCLEBIN：全库清，必须SYSDBA，但高并发时会持全局锁，可能卡住其他会话 - 单个对象清理：
PURGE TABLE "BIN$abc123$0"（注意双引号包裹伪名），适合只想删某几个大对象又想留别的
不支持 WHERE 过滤，也别指望加条件筛选——Oracle 不提供这种语法。
清完空间还不涨？检查这三处
执行成功后 DBA_FREE_SPACE 没变化，大概率不是命令失败，而是空间没“活”过来：
- 数据文件本身不会自动缩小；
df -h看磁盘不变是正常的，重点查SELECT SUM(bytes) FROM dba_free_space WHERE tablespace_name = 'USERS';是否上涨 - 如果表空间是
AUTOEXTEND ON，旧空间只是标记为“可重用”，下次建表或插入时才复用，不会主动返还给操作系统 - 某些 LOB 段或大分区对象可能残留；查
DBA_LOBS和DBA_TAB_PARTITIONS，确认是否有未清理的关联段
真正释放物理空间，得靠后续动作：比如对表执行 ALTER TABLE t SHRINK SPACE CASCADE（需 ASSM 表空间 + 启用行移动），或手动 ALTER DATABASE DATAFILE 'xxx.dbf' RESIZE（前提是 dba_free_space 显示顶部有连续空闲块）。
