第一反应是主库未启用归档或日志传输未激活：需确认log_mode为archivelog、log_archive_dest_2配置有效且非disable、archive_lag_target合理设置（60–180秒），并验证lgwr进程状态为connected及告警日志无ora-16057等错误。
检查 ARCHIVE_LAG_TARGET 和日志传输是否启用
备库收不到日志，第一反应不是网络或权限问题，而是主库根本没在传。Oracle Data Guard 日志传输依赖归档日志生成和传输机制是否真正激活。
- 确认主库是否启用了归档模式：
SELECT log_mode FROM v$database;必须返回ARCHIVELOG - 检查主库是否配置了有效归档目的地：
SHOW PARAMETER log_archive_dest_2（或其他用于 DG 的log_archive_dest_n）——值不能是空、DISABLE或MANDATORY但未配有效服务名 -
ARCHIVE_LAG_TARGET设为 0 或未设置时，归档可能只在日志切换时触发，导致备库长时间无新日志；建议设为 60～180（秒），强制定时归档
验证 LGWR 进程是否正常连接备库
日志传输由 LGWR（实时传输）或 ARCH（归档后传输）进程完成，多数生产环境用 LGWR SYNC/ASYNC。若 LGWR 进程挂起或无法连接，日志就卡在主库内存中。
- 查看主库后台进程状态：
SELECT process, status, client_process, sequence#, block# FROM v$managed_standby;
若process = 'LGWR'且status = 'CONNECTED'，说明链路通；若为NOT ACTIVE或FAILED，需进一步查错 - 检查主库告警日志（
background_dump<em>dest</em>下的alert<sid>.log</sid>），搜索关键词：LGWR、ORA-16057（DG 配置缺失）、ORA-12541（TNS 连接拒绝）、ORA-16714（参数不一致）
确认备库 STANDBY_FILE_MANAGEMENT 和 REDO APPLY 状态
即使日志传过来了，备库若没启动应用，也会表现为“没收到”——其实是收到了但没处理，v$archived_log 里有记录，v$managed_standby 却显示 ARCH 进程空闲。
- 查备库是否启用了自动日志应用：
SELECT database_role, open_mode, protection_mode, guard_status FROM v$database;open_mode应为MOUNTED（非READ ONLY），否则REDO APPLY无法运行 - 检查应用进程：
SELECT process, status, thread#, sequence# FROM v$managed_standby WHERE process IN ('MRP0', 'RFS');MRP0是日志应用进程，status必须是APPLYING_LOG；若为WAIT_FOR_LOG，说明 RFS 进程没收到新日志；若为NOT APPLYING，需手动启动：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 注意
STANDBY_FILE_MANAGEMENT=AUTO必须开启，否则新增数据文件会导致ORA-01119类错误并中断应用
排查 TNS 连接与密码文件一致性
Data Guard 要求主备库使用相同密码文件（orapw<sid></sid>），且 TNS 名称在两端 tnsnames.ora 中必须能双向解析——这点极易被忽略，尤其在跨平台或重命名实例后。
- 主库测试连备库：
tnsping <standby_tns_alias></standby_tns_alias>，再sqlplus sys/<pwd>@<standby_tns_alias> as sysdba</standby_tns_alias></pwd>
备库同样要能反向连主库（RFS 进程需要建立到主库的连接来拉取日志） - 密码文件必须包含
SYS用户且具有sysdba权限；用orapwd file=$ORACLE_HOME/dbs/orapw<sid> password=<pwd> format=12</pwd></sid>重建时，务必保证format版本与数据库一致（12c+ 推荐format=12） - 若主备 SID 不同，
log_archive_dest_2中的service=必须指向备库监听的正确 SID，不能仅靠主机名和端口判断
实际排查中最容易卡住的是：主库 log_archive_dest_state_2 被设为 DEFER，或者备库 REDO APPLY 停在某个中断点后没清日志 gap 就直接重启 MRP，结果反复卡在同一个 sequence 上。遇到 gap，先查 SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;，再手工拷贝缺失归档过去，再 ALTER DATABASE REGISTER LOGFILE '...'; 注册。
