Oracle回收站对象占满表空间如何清理

回收站对象确实占用表空间，段名改为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 gbFROM 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 为什么没效果？

常见失败不是命令写错，而是卡在权限、容器或对象状态上：

1. 必须用 SYS 或有 SYSDBA 权限的用户执行；SELECT * FROM SESSION_ROLES; 查不到 DBA 就别硬试，会报 ORA-01031
2. 多租户环境下，默认在 CDB$ROOT 执行会清掉所有 PDB 的回收站；要精准清理某个 PDB，得先 ALTER SESSION SET CONTAINER = pdb_name;
3. 对象被其他会话正在查询或锁住时，会报 ORA-38301: can not perform DDL/DML over object in Recycle Bin；查 V$SESSION 和 V$LOCK 找出阻塞会话，必要时 ALTER SYSTEM KILL SESSION
4. 执行后无报错≠全清完；立刻再查 DBA_RECYCLEBIN，若还有记录，说明部分对象跳过了

该用哪个 PURGE 命令？别一上来就全库清

不同场景对应不同命令，选错可能误伤或无效：

1. PURGE RECYCLEBIN：只清当前用户自己的回收站，安全，普通用户也能跑
2. PURGE TABLESPACE users USER scott：只清 USERS 表空间里 scott 用户的对象，精准低风险，适合局部空间告急
3. PURGE DBA_RECYCLEBIN：全库清，必须 SYSDBA，但高并发时会持全局锁，可能卡住其他会话
4. 单个对象清理：PURGE TABLE "BIN$abc123$0"（注意双引号包裹伪名），适合只想删某几个大对象又想留别的

不支持 WHERE 过滤，也别指望加条件筛选——Oracle 不提供这种语法。

清完空间还不涨？检查这三处

执行成功后 DBA_FREE_SPACE 没变化，大概率不是命令失败，而是空间没“活”过来：

1. 数据文件本身不会自动缩小；df -h 看磁盘不变是正常的，重点查 SELECT SUM(bytes) FROM dba_free_space WHERE tablespace_name = 'USERS'; 是否上涨
2. 如果表空间是 AUTOEXTEND ON，旧空间只是标记为“可重用”，下次建表或插入时才复用，不会主动返还给操作系统
3. 某些 LOB 段或大分区对象可能残留；查 DBA_LOBS 和 DBA_TAB_PARTITIONS，确认是否有未清理的关联段

真正释放物理空间，得靠后续动作：比如对表执行 ALTER TABLE t SHRINK SPACE CASCADE（需 ASSM 表空间 + 启用行移动），或手动 ALTER DATABASE DATAFILE 'xxx.dbf' RESIZE（前提是 dba_free_space 显示顶部有连续空闲块）。