备库执行RMAN备份可避免主库I/O和CPU争用，但必须在主库配置ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY，否则归档堆积致ORA-19809；备份集仅适用于备库还原或搭建新备库，不可直接用于主库PITR。
备库执行RMAN备份能避免主库I/O和CPU争用
主库承担在线事务处理（oltp），任何rman备份都会触发大量物理读、归档日志扫描、压缩和写入操作，直接抢占sga/pga内存、磁盘带宽与cpu周期。在高并发场景下，backup database plus archivelog 可能导致主库响应延迟升高、log file sync 等待加剧，甚至触发ora-04030（内存耗尽）。而备库通常只做日志应用，资源余量充足，把备份任务迁过去，主库负载曲线几乎不受扰动。
RMAN在备库备份时必须启用ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
这是最关键的配置前提，否则会出严重问题：
- 不配该策略 → RMAN默认
ARCHIVELOG DELETION POLICY为NONE→ 即使备库已成功应用某段归档，主库仍不会自动清理它 → 归档持续堆积 → 闪回区满 →ORA-19809→ 数据库hang住 - 配了该策略 → 主库的
delete obsolete或backup archivelog all delete input才会真正删除“已在备库APPLIED”的归档 → 归档生命周期可控 - 注意：该策略需在主库执行：
configure archivelog deletion policy to applied on standby;，不是在备库配
备库备份生成的是“可传输备份集”，但恢复路径受限
在备库执行backup database，RMAN实际备份的是当前应用到的SCN对应的数据文件快照（即“物理一致性”状态），而非主库实时状态。这意味着：
- 备份集可用于还原备库自身，或作为新备库的起点（
duplicate target database for standby） - 不能直接用于主库故障后的“时间点恢复（PITR）”，因为缺少主库后续未传输到备库的归档日志
- 若要用该备份恢复主库，必须确保主库归档已全部传到备库并应用完成，且你有完整归档链（含主库最后切换前的current log）
- 备份中不包含主库的在线redo log（RMAN本来就不能备份它），所以别指望靠这个备份“回退主库未提交事务”
真实场景下，备库备份常配合KEEP FOREVER和NOLOGGING规避风险
生产中极少让备库裸跑RMAN全备，更常见的是组合策略：
- 对只读表空间（如
EXAMPLE、历史分区表所在TS），在主库先执行backup tablespace EXAMPLE keep forever，后续全备自动跳过，减少备库备份压力 - 备库开启
FORCE LOGGING后，所有DML强制写redo，但某些NOLOGGING操作（如/*+ APPEND */直插）仍可能产生非日志块 —— 这类块在备库备份中是“逻辑一致但物理不可恢复”的，需提前识别并规避 - 若备库启用了
ACTIVE DATA GUARD并开放只读查询，RMAN备份期间可能遇到ORA-01157（无法识别数据文件），需确认备库处于MOUNT或READ ONLY WITH APPLY状态再执行
备库RMAN备份不是“主库备份的平替”，而是主备架构下一种资源隔离、归档治理和灾备链路加固的协同动作。最容易被忽略的一点是：它依赖主库参数配置生效，而不是备库自己决定能删哪些归档 —— 那个configure archivelog deletion policy命令，必须在主库连上RMAN后执行，且要验证show all输出里确实生效，否则一切备份都只是在给闪回区埋雷。
