不会直接阻塞普通dml，但会获取svs锁清理回收站元数据，可能短暂阻塞对dba_recyclebin的查询及依赖该视图的后台操作；rac环境下触发跨实例协调，影响gc等待和恢复操作；“0 rows affected”不等于清空，需查dba_recyclebin确认；空间不会立即释放至os。
执行 PURGE DBA_RECYCLEBIN 会阻塞 DML 吗？
不会直接阻塞普通 DML（如 INSERT/UPDATE/DELETE），但它会获取全局锁（SVS lock）扫描并清理整个数据库的回收站元数据，期间可能短暂阻塞其他会话对 DBA_RECYCLEBIN 视图的查询、以及依赖该视图的后台操作（比如某些监控脚本或自动任务）。高并发场景下，若回收站对象极多（数万以上），这个锁持有时间可能达数秒到数十秒。
PURGE DBA_RECYCLEBIN 在 RAC 环境下的实际影响
命令在当前实例上执行，但清理的是整个集群共享的回收站元数据。它会触发跨实例协调，可能导致：
- 其他实例上正在访问同一回收站对象的会话报
ORA-38301: can not perform DDL/DML over object in Recycle Bin - GC（Global Cache）相关等待上升，尤其当回收站里有大表段（GB 级）时，段头块清理和 extent 位图更新会产生额外跨节点通信
- 如果某 PDB 正在做
FLASHBACK DATABASE或恢复，该命令可能被挂起，直到恢复完成
为什么“没报错”不等于“清完了”？
常见误判：执行完 PURGE DBA_RECYCLEBIN 返回 “0 rows affected”，就认为回收站空了。其实：
- 部分对象因状态异常（如被物化视图日志引用、处于
UNUSABLE分区索引状态）会被跳过，不报错也不清理 - 多租户环境下，若未显式
ALTER SESSION SET CONTAINER = pdb_name，CDB$ROOT 下执行只清理当前容器，PDB 内对象仍残留 - 执行后必须立刻查
SELECT COUNT(*) FROM DBA_RECYCLEBIN确认结果，不能仅凭 SQL*Plus 提示判断
真正释放空间前最容易忽略的一点
即使 PURGE DBA_RECYCLEBIN 成功且 DBA_RECYCLEBIN 为空，表空间的 DBA_FREE_SPACE 也不会立刻变大——Oracle 只是把对应 Extent 标记为“可重用”，并不主动 shrink 数据文件或归还 OS 空间。业务写入新数据时才会复用这些空闲 Extent；若长期无写入，df -h 看磁盘使用率毫无变化是正常现象。别因此反复执行 PURGE。
