RMAN中不存在SET ARCHIVELOG DEST命令，执行会报错；归档路径必须通过ALTER SYSTEM SET LOG_ARCHIVE_DEST_1在MOUNT状态下修改，且需重启生效，仅影响后续生成的归档日志。
RMAN里不能用 SET ARCHIVELOG DEST 修改归档路径
这个命令根本不存在——set archivelog dest 不是 rman 的合法命令，执行会直接报错 rman-00571 或 rman-00569。归档路径是数据库实例级配置，必须通过 sql 命令在 sql*plus 或 rman 的 sql 子命令中修改，rman 本身不管理归档目标。
改归档路径必须进 SQL*Plus 或用 RMAN 的 SQL 命令块
核心操作是修改 LOG_ARCHIVE_DEST_1 参数，且数据库需处于 MOUNT 状态（不是 NOMOUNT，也不是 OPEN）：
- 先关闭数据库：
SHUTDOWN IMMEDIATE - 启动到 mount：
STARTUP MOUNT - 执行 SQL 修改（两种等效写法任选）：
— 方式一（SQL*Plus）：ALTER SYSTEM SET log_archive_dest_1='LOCATION=/new/arch/path' SCOPE=SPFILE;
— 方式二（RMAN 内）：RUN { SQL "ALTER SYSTEM SET log_archive_dest_1=''LOCATION=/new/arch/path'' SCOPE=SPFILE"; } - 重启生效：
SHUTDOWN IMMEDIATE; STARTUP;
注意：Windows 路径要用双反斜杠或正斜杠，比如 'LOCATION=D:\oracle\arch' 或 'LOCATION=D:/oracle/arch'；Linux 路径末尾不加斜杠。
改完路径后归档日志不会自动迁移，旧归档仍留在原位置
修改 log_archive_dest_1 只影响后续生成的归档日志，已存在的归档文件不会被移动或复制。如果异机恢复或清理归档，你得手动搬运旧归档到新路径，否则 RECOVER DATABASE 时可能报错找不到归档日志，例如：ORA-00308: cannot open archived log '/old/path/1_12345_1234567890.arc'。
- 确认当前归档路径：
ARCHIVE LOG LIST或查视图SELECT DEST_NAME, STATUS, TARGET FROM V$ARCHIVE_DEST WHERE DEST_NAME = 'LOG_ARCHIVE_DEST_1'; - 检查新目录权限：
ls -ld /new/arch/path，确保oracle用户有读写权限 - 强制切换一次日志验证：
ALTER SYSTEM SWITCH LOGFILE;，再查ls /new/arch/path是否出现新归档文件
异机恢复时归档路径不一致会导致 recover 失败
目标库的 log_archive_dest_1 路径和源库备份时的归档存放路径不一致，RECOVER DATABASE 会默认去读取源库路径下的归档——但那个路径在目标机上通常不存在或为空。
- 最稳妥做法：恢复前，在目标库先按源库归档路径建好对应目录（哪怕只是软链接），例如源库归档在
/u01/app/oracle/archivelog，目标机就执行：mkdir -p /u01/app/oracle/archivelog - 或者改目标库参数匹配源路径（更推荐）：
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog' SCOPE=SPFILE;，再重启 - 切勿依赖
SET ARCHIVELOG DEST或幻想 RMAN 自动重定向——它根本不处理这个逻辑
归档路径配置是恢复链里最易被跳过的环节，一旦漏掉，RECOVER 就卡在“找不到归档”上，而错误提示里往往不直接告诉你该去改哪个参数。
