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和DUMPFILE=export_<job_name>_%U.dmp，便于按作业名批量识别 - 清理脚本应检查文件修改时间 + 是否被进程占用：
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）同样占空间且长期残留。 
