MRP0处于WAIT_FOR_LOG状态时，需检查SRL状态是否为UNASSIGNED且线程号匹配、DEST_ID=2的ERROR是否为空、备库是否启用FORCE LOGGING、SRL大小是否≥主库最大日志文件字节数、RFS是否真正写入SRL而非归档目录、log_archive_dest_2是否配置为LGWR ASYNC AFFIRM=NO并含VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)。
MRP进程显示WAIT_FOR_LOG但RFS状态正常怎么办
MRP0处于WAIT_FOR_LOG状态，不代表RFS没干活——它可能已收完日志，但SRL还没就绪或归档路径配置有误，导致MRP无法启动实时应用。关键不是看RFS是否RUNNING，而是看它有没有把日志真正写进Standby Redo Log。
- 查
V$STANDBY_LOG：STATUS必须是UNASSIGNED，不能是INVALID；THREAD#列值要和主库实例线程号严格一致 - 查
V$ARCHIVE_DEST_STATUS中DEST_ID=2的ERROR列：非空说明传输链路本身中断（比如网络不通、监听未注册、SERVICE_NAME错） - 确认备库是否启用了
FORCE LOGGING：虽然主库启用了，但备库自身也需满足该前提才能接受并应用所有重做流
为什么RFS接收成功但MRP不推进sequence#
RFS把归档或在线日志写进磁盘后，MRP仍卡在WAIT_FOR_LOG，大概率是SRL没被正确识别或大小不匹配。Oracle 19c对SRL校验更严格，稍有偏差就会静默拒绝使用。
- SRL单组大小必须≥主库
V$LOG中MAX(BYTES)值，小1字节都会触发ORA-00354，MRP直接跳过该日志流 - RAC环境漏配任意一个THREAD的SRL，对应实例产生的日志就永远进不了SRL，MRP只能等——但
V$ARCHIVE_GAP查不到缺口，V$DATAGUARD_STATS.transport_lag却持续上涨 - 别信
ALTER DATABASE ADD STANDBY LOGFILE返回“success”：必须立刻ls -l确认文件真实生成，且属主为oracle:oinstall，路径可写
如何验证RFS是否真把日志送进了SRL而非归档目录
RFS默认行为是优先写SRL，但若SRL不可用（如INVALID、路径不存在、权限不足），它会自动降级写入standby_archive_dest。这种“悄悄绕行”会导致MRP完全找不到待应用的日志。
- 查
V$MANAGED_STANDBY中RFS行的CLIENT_PROCESS列：如果是ARCH，说明它正在传归档；如果是LGWR或UNKNOWN，才表示走的是实时路径 - 查
V$STANDBY_LOG的FIRST_TIME和NEXT_TIME：应有近实时更新的时间戳；若全为空或长时间不变，说明RFS根本没往SRL里写 - 临时清空
standby_archive_dest目录（确保有备份），再观察alert.log：如果RFS开始报ORA-00313（无法打开成员），反而证明它原本就在往那里写——这就是问题根源
log_archive_dest_2配置错误导致RFS与MRP脱节
主库LOG_ARCHIVE_DEST_2若设成ARCH ASYNC，RFS只能等ARC进程把归档落盘后才收到；而设成LGWR ASYNC但没加AFFIRM=NO，LNS会卡在网络确认上，RFS收不到新日志，MRP自然干等。
- 执行
SHOW PARAMETER log_archive_dest_2，确认输出含LGWR ASYNC AFFIRM=NO和VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - RAC主库必须检查
VALID_FOR是否包含PRIMARY_ROLE：切换角色后，若此项缺失，归档传输会静默失效 - 备库侧禁用
standby_archive_dest：19c中它已非必需，残留配置反而干扰RFS路由逻辑，建议用ALTER SYSTEM RESET standby_archive_dest SCOPE=SPFILE清除
WAIT_FOR_LOG。最有效的排查方式，是交叉比对V$STANDBY_LOG内容、V$MANAGED_STANDBY中RFS的CLIENT_PROCESS、以及alert.log里RFS实际写入的目标路径。 
