暂停MRP但保持RFS接收，只需执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，该命令终止MRP0进程（状态变为NOT APPLYING或IDLE），而RFS仍正常接收重做数据；切回实时同步时执行USING CURRENT LOGFILE即可从SRL最新位置续应用。

如何暂停MRP但保持RFS日志接收

备库停掉mrp进程后，默认仍会通过rfs进程接收主库发来的重做数据——前提是归档传输没被手动禁用。关键在于：mrp（日志应用）和rfs（日志接收）是两个独立进程，停止前者不影响后者运行。

实操上只需执行一条命令即可暂停应用，同时保留传输链路畅通：

• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; —— 这会终止MRP0进程，状态变为NOT APPLYING，但RFS照常写SRL或归档日志
• 确认MRP已停：SELECT PROCESS, STATUS FROM v$managed_standby WHERE PROCESS = 'MRP0';，返回空或STATUS = 'IDLE'即成功
• 检查RFS是否仍在工作：SELECT PROCESS, STATUS, CLIENT_PROCESS FROM v$managed_standby WHERE PROCESS = 'RFS';，只要STATUS不是FAILED且CLIENT_PROCESS为LGWR或ARCH，说明接收正常

为什么不能只关LGWR或设DEFERRED？

误以为“关闭日志传输”就能“只收不应用”，其实是混淆了传输层和应用层。若在主库把LOG_ARCHIVE_DEST_2设为DEFERRED，或停掉LGWR进程，RFS根本收不到新数据，备库日志就会断流，后续恢复时可能触发ORA-01547或gap问题。

• DEFERRED是传输开关，一关就断收；而CANCEL只是应用开关，收不停
• RAC环境尤其要注意：必须在每个主库实例执行ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;，否则部分节点传输静默失败，你以为“还在收”，其实只有一半在干活
• 如果主库用的是ARCH异步传输，备库即使停MRP，也只会收到归档而非实时流，延迟天然偏高；建议优先确保主库配置LGWR ASYNC，再停MRP

常见错误现象：MRP停了，但RFS也挂了

典型表现是v$managed_standby里RFS显示FAILED或UNKNOWN，ALERT.log里出现TNS-12545、ORA-12170或ORA-01034。这不是MRP命令的问题，而是网络或监听配置崩了。

• 检查主库tnsping备库SCAN名：tnsping standby-scan.example.com，必须返回至少两个VIP地址，否则RAC下RFS连接不稳定
• 确认备库tnsnames.ora中DG服务名（如standby_DGB）已注册到所有节点的listener.ora，且SERVICE_NAME与LOG_ARCHIVE_DEST_2中一致
• 别忽略ASM路径权限：若RFS尝试写SRL到+DATA_STBY但权限不足，会静默失败，查v$asm_diskgroup的STATE和TYPE是否为MOUNTED和REGULAR

停MRP后还能不能切回实时同步？

能，而且几乎无损。只要RFS一直在收，SRL文件持续增长，重新启动MRP时加USING CURRENT LOGFILE即可立刻从SRL最新位置开始应用，不会重扫归档。

• 重启命令：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
• 若之前停MRP时间较长，先查v$archive_gap确认有无缺失序列；有gap需手工拷贝补上，否则启动报ORA-01153
• 注意：不要在MRP运行时重复执行该命令，会触发冲突错误；务必先CANCEL再重起

最易被忽略的一点：停MRP期间，备库控制文件里的SCN不会推进，但SRL文件头记录的First SCN和Next SCN仍在更新。这意味着你看到的“当前日志序列”可能比v$archived_log里最大值还大几号——这正是RFS在默默工作的证据。