暂停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 vmanaged_standby WHERE PROCESS = 'MRP0';,返回空或STATUS = 'IDLE'即成功检查RFS是否仍在工作:SELECT PROCESS, STATUS, CLIENT_PROCESS FROM vmanaged_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命令的问题,而是网络或监听配置崩了。 WisPaper 复旦大学研发的AI学术搜索工具,5分钟内筛选1000篇论文
相关推荐
zhaoshuzhaoshu2 小时前
Python 语法之控制结构详解Engineer邓祥浩2 小时前
JVM学习笔记(8) 第三部分 虚拟机执行子系统 第7章 虚拟机类加载机制xcbrand2 小时前
工业制造品牌全案公司找哪家dualven_in_csdn2 小时前
EMQX 开启 **MySQL + password_based** 认证深蓝海拓2 小时前
基于QtPy (PySide6) 的PLC-HMI工程项目(七)上位机通信部分的初步建设:socket客户端神秘剑客_CN2 小时前
python安装requests及pandas人工智能AI技术2 小时前
Python 循环基础:for、while、break、continueJul1en_2 小时前
【Redis】单线程模型Arva .2 小时前
Spring 事务传播机制 速记