Data Pump转储文件不会被RMAN自动识别或管理，必须手动清理；RMAN的DELETE命令对其无效，因其不注册到RMAN资料库，也不受保留策略约束。

Data Pump 转储文件本身**不会被 RMAN 自动识别或管理**，清理必须手动干预；RMAN 的 DELETE 命令对 .dmp 文件完全无效——这是最常被误踩的坑。

为什么不能用 RMAN 删除 Data Pump 转储文件

rman 只跟踪它自己创建的备份集（backupset）、镜像副本（datafilecopy）和归档日志等对象，所有元数据都记录在控制文件或恢复目录中。而 data pump 导出生成的 .dmp 文件是纯粹的二进制文件，不注册到 rman 资料库，也不受 configure retention policy 约束。

• LIST BACKUP、REPORT OBSOLETE 等命令永远看不到 .dmp 文件
• DELETE OBSOLETE 或 DELETE BACKUP 对它们无任何作用
• 误以为“启用了快速恢复区（FRA）就能自动清理”会导致磁盘悄悄爆满

安全清理 Data Pump 转储文件的实操路径

必须靠操作系统级清理，但需严格绑定 Data Pump 作业生命周期，避免删错正在使用的文件。

• 导出时务必使用 DIRECTORY 对象（如 DATA_PUMP_DIR），而非绝对路径——这样可统一管控文件位置
• 在 expdp 命令中加 LOGFILE=export_<job_name>.log</job_name> 和 DUMPFILE=export_<job_name>_%U.dmp</job_name>，便于按作业名批量识别
• 清理脚本应检查文件修改时间 + 是否被进程占用：find /path/to/dump -name "*.dmp" -mtime +7 -not -exec fuser {} \; -delete
• 生产环境建议配合 crontab 每日凌晨执行，并将删除日志重定向到 /var/log/datapump_cleanup.log

与 RMAN 策略协同的关键设计点

虽然 RMAN 不管 .dmp，但二者共享存储资源，必须从容量规划层面统一约束。

• 把 Data Pump 目录（如 DATA_PUMP_DIR）和 RMAN 快速恢复区（DB_RECOVERY_FILE_DEST）**物理隔离**：不同挂载点、不同磁盘阵列
• 对 DATA_PUMP_DIR 所在文件系统设置 quota 或监控告警（如 df -h | grep datapump > 85% 就触发通知）
• 若使用 ASM，为 Data Pump 创建专用磁盘组（如 +DUMPGRP），并配置 USAGE_LIMIT 防止无限增长
• 绝不允许将 DUMPFILE 写入 FRA 目录——RMAN 不会清理它，反而可能因空间不足中断自身备份

真正麻烦的不是“怎么删”，而是“删完之后如何确认没漏掉新生成的临时转储”。很多团队只清理 .dmp，却忘了 .log 和 .sql（如 INCLUDE=METADATA_ONLY 生成的 DDL）同样占空间且长期残留。