Oracle 12c备库日志应用延迟，如何检测Recovery与LGWR进程异常？

本文共计995个文字，预计阅读时间需要4分钟。

相关专题：

备库没在实时应用日志，90% 是 mrp 没真跑起来，或 lgwr 传输根本没发出去——别只看进程名，得查状态、查路径、查归档缺口。

查 v$managed_standby 确认 MRP 是否真在 APPLYING_LOG

MRP 进程名存在 ≠ 在干活。它可能卡在 WAIT_FOR_LOG 或静默 halt，表面看是“运行中”，实际已停摆。

• 执行 SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0';，status 必须是 APPLYING_LOG 才算有效工作；若为 WAIT_FOR_LOG，大概率是遇到 UNNAMED 数据文件（ORA-01111）或控制文件不一致
• 若返回空行，说明 MRP 根本没启动：检查是否执行过 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
• 别信 ps aux | grep mrp —— 进程可能残留但内部已退出，v$managed_standby 才是唯一可信来源

查 v$archive_dest_status 判断 LGWR 传输是否卡在主库

主库侧的传输失败，备库连日志影子都收不到。重点不是“有没有配”，而是“配对了没、启用了没、连通了没”。

• 执行 SELECT DEST_ID, STATUS, ERROR, TRANSMIT_MODE, RECOVERY_MODE FROM v$archive_dest_status WHERE DEST_ID = 2;（假设备库为 DEST_ID=2）
• ERROR 字段非空即故障：常见如 ORA-12541: TNS:no listener（主库连不上备库监听）、ORA-16057: DG Broker configuration is missing（Broker 配置缺失）
• TRANSMIT_MODE 应为 SYNC 或 ASYNC，若为 ARCH，说明走的是归档进程而非 LGWR 实时传输
• RECOVERY_MODE 在备库上应为 MANAGED REAL TIME APPLY；若为 IDLE，说明主库压根没把日志推过来

用 v$archive_gap 定位归档缺口，区分“传不过去”和“收不到”

有 gap ≠ 网络问题。先确认缺口是否存在，再决定是主库补传，还是备库手动注册。

• 在备库执行 SELECT * FROM v$archive_gap;，若有记录，说明主库某段归档日志未抵达备库（传输中断），不是应用慢的问题
• 若无记录，但 v$managed_standby 中 MRP status 是 WAIT_FOR_LOG，则极可能是备库缺数据文件（UNNAMED）或归档校验失败（如手动拷贝时修改过文件时间戳）
• 注意：gap 范围中的归档，必须在主库 LOG_ARCHIVE_DEST_1 目录下真实存在；若已被清理，需从备份恢复，不能靠 RMAN FROM SERVICE 自动补全（尤其含新增数据文件时）

验证 LGWR/LNS 进程是否真在写，而非假连接

LNS 进程挂了，LGWR 传输就断了。但它不像数据库实例会报错退出，容易被忽略。

• 在主库执行 SELECT process, status, sequence# FROM v$managed_standby WHERE process IN ('LNS', 'ARCH');
• LNS 行的 status 应为 WRITING 或 OPEN；若为 CLOSING、NOT ACTIVE 或为空，说明 LGWR 传输链路已中断
• 常见原因：主库 LOG_ARCHIVE_DEST_2 的 VALID_FOR 设为 (ONLINE_LOGFILES, PRIMARY_ROLE)（错误配成主库角色），导致备库角色下 LNS 不启动
• 临时验证：在主库执行 ALTER SYSTEM SWITCH LOGFILE;，立即查 v$managed_standby，看 LNS 是否响应新 sequence#

真正卡住的地方，往往藏在 v$archive_dest_status.ERROR 的一行报错里，或 v$managed_standby 中那个看似正常却 status 为 WAIT_FOR_LOG 的 MRP0。别跳过这一步直接重建控制文件——多数时候，它只是等着你手动注册一个归档，或创建一个 UNNAMED 文件。