RMAN生产备份必须显式配置归档删除策略，否则归档堆积导致闪回区满、数据库hang；默认ARCHIVELOG DELETION POLICY为NONE，不自动删归档；常用策略为backed up 1 times to disk，需配合backup archivelog all delete input执行。
rman 生产环境备份不能只靠 backup database 一把梭，必须显式配置排除策略，否则归档暴增、控制文件膨胀、闪回区撑爆是分分钟的事。
为什么默认不自动排除归档日志
RMAN 默认的 ARCHIVELOG DELETION POLICY 是 NONE，意味着它永远不会主动删归档——哪怕你刚备份完、归档已无恢复价值。这和很多人直觉相反：以为“备份完就安全了”，实际只是把归档从 ARCHIVELOG 目录搬到了 BACKUPSET，原归档还在原地占空间。
- 归档日志堆积直接触发
ORA-19809（闪回恢复区超限），严重时数据库 hang 住 - 没配删除策略时，
delete obsolete不会动归档，只清理数据文件/控制文件备份 - 即使开了
CONTROLFILE AUTOBACKUP，若没指定FORMAT，自动备份可能写到 $ORACLE_HOME/dbs 下，和生产路径混在一起，后期难追溯
configure archivelog deletion policy 的三种典型用法
该命令决定 RMAN 在什么条件下允许删除归档日志，必须在连接目标库后执行：
-
configure archivelog deletion policy to applied on standby;—— 仅当归档已在物理备库上APPLIED后才可删，适合 Data Guard 环境 -
configure archivelog deletion policy to backed up 1 times to device type disk;—— 归档被成功备份到磁盘至少 1 次后即可删，最常用，但需确保备份脚本里真执行了backup archivelog all delete input -
configure archivelog deletion policy to none;—— 禁用策略，所有归档永不自动删；仅用于调试或短期保留需求，上线前务必改掉
注意：backed up N times 不等于“备份过 N 次”，而是指“被某次 backup archivelog 命令覆盖并成功写入备份集的次数”。一次全量归档备份就能满足 backed up 1 times 条件。
exclude 参数不是万能的，慎用于表空间级排除
RMAN 支持在 backup database 中用 exclude tablespace 跳过某些表空间，但生产环境极少推荐：
-
exclude tablespace 'USERS'之类写法看似省事，但一旦该表空间后来被设为READ ONLY或含关键对象（如审计表、调度作业日志），跳过会导致恢复链断裂 - 排除后，RMAN 不再校验该表空间的块一致性，
validate和check logical失效 - 更稳妥的做法是：对只读表空间单独做一次
backup tablespace+keep forever，后续全备中启用backup optimization on自动跳过未变更部分
backup ... not backed up 与 retention policy 的冲突点
想用 backup database not backed up since time='sysdate-7' 实现“只备最近一周没备过的数据文件”，得先确认 retention policy 不会反向干扰：
- 如果设的是
recovery window of 7 days，RMAN 可能判定“7天内已有完整备份”，于是not backed up返回空结果，导致本次备份啥都不做 - 如果设的是
redundancy 1，则只要存在任意一份有效全备，not backed up就不会触发新备份 - 真正可控的方式是：用
configure retention policy to none+ 显式加not backed up+ 配合外部脚本定时清理旧备份（别依赖delete obsolete）
生产环境最易被忽略的是：not backed up 判定依据是 RMAN 目录里的 BS_KEY 记录，不是文件系统是否存在备份文件。如果曾手工删过备份集但没跑 crosscheck backup; delete expired，RMAN 仍认为“已备份”，导致漏备。
