备库归档路径权限不足会导致rfs静默失败、mrp卡住；需查alert.log中ora-01031/027040等错误，用namei -l验证各级目录x权限，再chown/chmod修复并重启传输链路。
备库归档路径权限不足时，rfs进程写入归档日志会静默失败，mrp进程随后卡住，alter database recover managed standby database 命令看似执行成功，但v$managed_standby中rfs状态长期为idle或connected却不写文件，v$archived_log里最新记录停在很久以前——这不是网络或fal配置问题，是操作系统层面的硬性拦截。
怎么确认真是权限问题而不是路径不存在
别直接改权限。先验证是否真因权限触发失败：
- 查备库
alert.log，搜索RFS和ORA-01031、ORA-27040、ORA-27037等I/O类错误；若出现file creation failed或permission denied字样，基本锁定权限 - 用
ps -ef | grep rfs确认RFS进程是否在运行；再查其属主：ls -l /proc/<i>pid</i>/exe，确认是oracle用户启动 - 手动模拟写入：切到
oracle用户，执行touch /u01/arch/TEST_$$（$$是当前shell PID），若报Permission denied，就是目录权限或父目录执行位缺失 - 检查整个路径链：
namei -l /u01/arch，看每一级是否对oracle用户有x（进入）权限；常见坑是/u01属主为root:root且权限为755，oracle能进，但/u01/arch属主为root且权限为755，oracle无写权
修改归档路径权限的正确操作顺序
Oracle要求归档目标路径必须满足两个条件：存在且oracle用户可写；父目录必须对oracle用户有执行（x）权限——否则连chdir都失败，更别说创建文件。
- 确认当前归档路径：
SELECT DEST_NAME, STATUS, TARGET, LOCATION FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;，记下LOCATION值（如/u01/arch） - 逐级设置权限：
chown -R oracle:oinstall /u01/arch，然后chmod 755 /u01（确保oracle能进入）、chmod 775 /u01/arch（确保可写） - 严禁只改
/u01/arch权限而忽略/u01的x位；也严禁用777，RMAN和DBWR后续可能拒绝写入 - 若路径在ASM上，权限问题不适用，应检查
asm_diskstring和磁盘组挂载状态，而非本节操作
改完权限后必须做的三件事
权限修复只是第一步，RFS不会自动续传中断期间的归档，必须人工触发链路重连与补缺：
- 重启RFS通道：在主库执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;再=ENABLE;，强制ARCn重连并重传最近几个序号 - 检查备库
ALERT日志，确认出现RFS[?]: Archived Log Added，而非继续报错；若仍无反应，检查tnsnames.ora中备库服务名能否被主库tnsping通 - 若归档已堆积在主库但未传过来，需手动
scp缺失段（如arch_1_12345.arc）到备库/u01/arch/，再在备库RMAN中CATALOG START WITH '/u01/arch/';注册，否则MRP视而不见
权限修复本身很简单，难的是判断时机——当v$archive_dest_status显示VALID但STANDBY_ARCHIVED_LOG_COUNT不动，且alert.log没明显报错时，最容易忽略这个底层原因。系统不会告诉你“你少了个x位”，只会让同步停在那里，等你一层层namei下去。
