adg备库打开后mrp进程停止或卡住的常见现象是执行alter database open read only后状态变为wait_for_log或not applying，根本原因是未启用real-time apply且数据库未处于read only with apply模式；必须在mount状态下执行using current logfile命令启动mrp，并确保standby redo log配置正确、service_names隔离及资源合理分配。
ADG备库打开后MRP进程停止或卡住
常见现象是备库执行ALTER DATABASE OPEN READ ONLY后，V$MANAGED_STANDBY中MRP进程状态变成WAIT_FOR_LOG或NOT APPLYING，日志不再应用，查询看似正常但数据持续滞后。这不是“打开了就能用”，而是没启用Active Data Guard的实时应用机制。
根本原因是：物理备库默认不支持“边应用边只读”。必须启用REAL-TIME APPLY，且数据库需处于READ ONLY WITH APPLY模式，而非单纯READ ONLY。
- 确认当前模式：
SELECT OPEN_MODE FROM V$DATABASE;—— 正确值应为READ ONLY WITH APPLY；若为READ ONLY，说明ADG未生效或未正确启动 - 启用实时应用（仅在MOUNT状态下有效）：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 检查是否已启用：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';—— 状态必须是APPLYING_LOG - 如果MRP报
ORA-16004或ORA-01153，先停MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再重新启动带USING CURRENT LOGFILE的命令
查询导致重做日志应用延迟甚至中断
即使MRP在运行，大量并发只读查询仍可能间接拖慢日志应用——尤其当备库I/O或CPU资源不足时。Oracle不会直接“阻塞”MRP，但MRP和用户查询共用SGA、Buffer Cache及磁盘I/O通道，高负载下重做块解析和应用速度下降，表现为V$LOGSTDBY_PROGRESS中APPLIED_SCN与CURRENT_SCN差值扩大。
关键不是限制SQL，而是隔离资源路径：
- 设置独立服务名并绑定资源计划：
ALTER SYSTEM SET SERVICE_NAMES='orcl_ro' SCOPE=BOTH;，再用DBMS_RESOURCE_MANAGER为orcl_ro服务分配专用CPU和I/O份额 - 禁用备库的
RESULT_CACHE（易与MRP争抢内存）：ALTER SYSTEM SET RESULT_CACHE_MODE=MANUAL SCOPE=BOTH; - 避免在备库执行大表全扫描或
/*+ PARALLEL */查询——这些会抢占Buffer Cache，导致MRP频繁等待db file sequential read - 监控争用信号：
SELECT EVENT, WAIT_TIME_MILLIS FROM V$SESSION_EVENT WHERE EVENT IN ('log file sync', 'db file sequential read', 'buffer busy waits') ORDER BY WAIT_TIME_MILLIS DESC;
tnsnames.ora配置错误导致查询打到主库
表面上看备库没被阻塞，实际所有只读流量都压在主库上，主库LGWR和LNS进程满负荷，反过来拖慢归档传输，最终让备库MRP因收不到新日志而停滞。这是最隐蔽也最常见的“伪ADG”问题。
必须确保客户端明确连接备库服务：
- 主库
tnsnames.ora里不要定义SERVICE_NAME为orcl_ro；该服务名只应在备库监听器中注册 - 备库执行：
ALTER SYSTEM SET SERVICE_NAMES='orcl_ro' SCOPE=BOTH;，然后lsnrctl reload - 客户端连接串必须显式使用
SERVICE_NAME=orcl_ro，不能复用主库的orcl服务名 - 验证路由是否生效：
SELECT INSTANCE_NAME, HOST_NAME FROM V$INSTANCE;—— 查询返回的主机名必须是备库机器名
备库未配STANDBY REDO LOG导致LGWR ASYNC传输失败
主库用LGWR ASYNC传输日志，但备库缺少STANDBY REDO LOG组，会导致日志写入失败，主库归档日志堆积，备库MRP只能靠轮询归档目录拉取，延迟飙升。此时V$ARCHIVE_DEST_STATUS.ERROR可能为空，但V$MANAGED_STANDBY中LNS状态为IDLE、RFS为WAIT_FOR_LOG。
STANDBY REDO LOG不是可选配置：
- 组数至少比主库
ONLINE REDO LOG多1组：SELECT GROUP#, THREAD#, BYTES/1024/1024 MB FROM V$LOG;→ 备库建等量+1组 - 大小必须严格一致：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/oradata/stdby/srl4.log' SIZE 200M; - 建完后重启备库（或至少
SHUTDOWN IMMEDIATE+STARTUP MOUNT），否则RFS进程不识别新组 - 确认生效：
SELECT GROUP#, TYPE, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;—— 新建组状态应为UNASSIGNED或ACTIVE
真正起作用的从来不是“开了ADG就自动分流”，而是每一处参数、服务名、日志组、资源计划都得对齐。最容易被忽略的是STANDBY REDO LOG大小匹配和SERVICE_NAMES的隔离——这两项出错，其余配置全白搭。
