“某张业务大表刚drop掉，磁盘空间纹丝不动，dba_free_space查半天没结果，连带着 DML 都卡死！”
根因定位
现象验证
-- 1. 刚 drop 的表确实还在
SELECT owner, original_name, droptime, space
FROM dba_recyclebin
WHERE original_name = 'BIG_ORDERS';
-- 2. 表空间使用率依然爆表
SELECT tablespace_name,
round(used_percent,2) pct
FROM dba_tablespace_usage_metrics
WHERE tablespace_name = 'TS_ORDERS';
结果：
BIG_ORDERS还在回收站里，占用 87 GB。- 表空间使用率 99 %，一分没少。
官方文档
The dropped objects continue to occupy space until you purge them explicitly or the tablespace runs out of free space. When the recyclebin is large, queries against data dictionary views (such as
DBA_FREE_SPACE) can become slower. —— Oracle® Database Administrator’s Guide
翻译：
- 不
purge就不会真正释放空间。 - 回收站对象多，
dba_free_space会慢成狗。 - 表空间快满时，后台为了“腾地儿”会抢资源，进而拖慢 DML。
一句话：回收站成了“合法”的垃圾场，空间是借出去了，但债还在。
清理方案
4.1 闪回 or 清理？
-- 如果有人想闪回，给他 10 分钟
FLASHBACK TABLE BIG_ORDERS TO BEFORE DROP;
-- 没人认领就直接Purge
PURGE TABLE BIG_ORDERS;
一键清空整个回收站（DBA 专用）
-- 清掉当前用户回收站
PURGE RECYCLEBIN;
-- 清掉全库所有用户的回收站（需要 SYSDBA）
PURGE DBA_RECYCLEBIN;
PURGE DBA_RECYCLEBIN会永久删除所有已 drop 的对象，闪回也救不回来。- 生产环境务必先备份或确认无闪回需求。
- 对 RAC 环境，需要在每个实例上执行一次，或者使用
GV$视图确认无残留。
清理效果
执行 PURGE DBA_RECYCLEBIN 后，立竿见影：
| 指标 | 清理前 | 清理后 |
|---|---|---|
| 回收站对象数 | 6 532 | 0 |
| 表空间使用率 | 99 % | 68 % |
dba_free_space 查询耗时 | 12 s | 80 ms |
| DML 平均响应时间 | 4.8 s | 120 ms |
防护措施 & 自动化
限制回收站空间
-- 每个用户最多留 1 GB
ALTER SYSTEM SET recyclebin = 'ON' SCOPE=BOTH;
ALTER SYSTEM SET recyclebin_retention = 1440; -- 单位分钟，24h
定期清理 Job
-- 每天凌晨 2 点自动清回收站
BEGIN
DBMS_SCHEDULER.create_job(
job_name => 'PURGE_RECYCLEBIN_DAILY',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN PURGE DBA_RECYCLEBIN; END;',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=DAILY; BYHOUR=2; BYMINUTE=0; BYSECOND=0',
enabled => TRUE);
END;
/
监控脚本
-- 如果表空间 > 90 % 且回收站对象 > 1000 就告警
SELECT 'ALERT: Recyclebin has '||COUNT(*)||' objects in '||tablespace_name
FROM dba_recyclebin
GROUP BY tablespace_name
HAVING COUNT(*) > 1000;
- 症状：drop 表不释放空间 → 回收站撑爆。
- 后果：
dba_free_space慢、DML 卡、表空间报警。 - 根因：Oracle 回收站默认“留一手”。
- 解药：
PURGE DBA_RECYCLEBIN，再配合定期 Job + 监控。