必须先确认数据库处于archivelog模式，否则backup archivelog会失败或无实际效果；检查方法为select log_mode from v$database，返回值必须是archivelog，若为noarchivelog则需shutdown immediate、startup mount、alter database archivelog、alter database open，并用archive log list验证归档路径有效。
必须先确认数据库处于 ARCHIVELOG 模式，否则 backup archivelog 会失败或无实际效果。
检查归档模式是否启用
这是最常被跳过的前置步骤。RMAN 备份归档日志的前提是数据库已开启归档，否则 v$archived_log 视图为空，backup archivelog 命令看似执行成功，实则什么都没备份。
- 连接到数据库后执行：
SELECT log_mode FROM v$database;—— 返回值必须是ARCHIVELOG - 若为
NOARCHIVELOG，需先关闭数据库、启动到MOUNT状态、执行ALTER DATABASE ARCHIVELOG;，再打开 - 确认归档路径有效：
ARCHIVE LOG LIST（在 SQL*Plus）或SHOW ALL（在 RMAN 中看ARCHIVELOG DESTINATION配置）
backup archivelog 命令的三种常用写法及差异
不同参数组合直接影响备份范围、归档日志是否被清理、以及能否满足 PITR（基于时间点恢复）需求。
-
backup archivelog all：备份所有已生成但尚未被 RMAN 标记为“已备份”的归档日志；不删除源文件 -
backup archivelog all delete input：备份后立即从原归档目录删除对应日志文件；适用于空间受限且确认备份可靠场景 -
backup archivelog from time 'sysdate-1'：只备份最近 24 小时产生的归档日志；适合配合增量备份做日志截断 - 注意：
delete input不等于delete noprompt—— 后者跳过确认，但前者仍可能因权限或文件锁定失败
为什么 backup archivelog all 经常报错 ORA-19693？
这是 RMAN 最典型的归档日志备份失败错误，根本原因是部分归档日志已被标记为“已备份”，但 RMAN 元数据与磁盘状态不一致。
- 常见诱因：手动删除过归档日志、未用 RMAN 清理、控制文件中记录过期
- 临时解决：
CHANGE ARCHIVELOG ALL CROSSCHECK;→DELETE EXPIRED ARCHIVELOG ALL; - 更稳妥做法：改用时间范围限定，如
backup archivelog from time 'sysdate-7' delete input;，避开历史脏记录 - 长期建议：启用恢复目录（
catalog），避免仅依赖控制文件存储元数据导致覆盖丢失
备份归档日志时容易忽略的两个关键点
一是归档日志路径不在快速恢复区（FRA）时，RMAN 默认不会自动识别其位置；二是备份后若未及时清理，FRA 可能因空间满触发 ORA-19809 错误，导致后续备份中断。
- 确保
DB_RECOVERY_FILE_DEST参数指向有效路径，且磁盘剩余空间 ≥ 数据库日均归档量 × 3 - 归档路径若在非 FRA 目录（如
/u01/arch/），需在 RMAN 中显式指定：CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK; - 生产环境强烈建议搭配
PLUS ARCHIVELOG一起使用全备命令，例如：backup database plus archivelog delete input;—— 这比分开执行更可控，避免中间窗口丢失新归档
归档日志备份本身不难，难点在于它和控制文件元数据、FRA 空间、归档路径权限三者之间的隐性耦合。一旦出问题，往往不是命令写错，而是某处状态没对齐。
