归档日志无法自动传送到备库，核心原因通常集中在网络连通性阻断、传输协议配置错误或备库接收服务未正常启动，需优先排查TNS配置与监听状态。
在Oracle数据库的高可用架构中,主备同步是保障数据零丢失的最后一道防线，当主库产生的归档日志（Archive Log）无法自动传输到备库进行应用时，整个容灾体系便处于“裸奔”状态，这不仅仅是日志堆积的问题，更是数据一致性断裂的前兆，很多DBA在面对这个问题时，第一反应是重启服务或检查磁盘空间，但这往往治标不治本，我们需要像排查电路故障一样，从信号源头到接收终端，一步步定位断点。
网络连通性与TNS配置排查
日志传输的第一步是“路”要通，很多时候，问题不出在数据库内部，而出在基础的通信链路上。
TNS名称解析与监听状态
主备库之间通过TNS（Transparent Network Substrate）进行通信，如果主库的tnsnames.ora文件中，指向备库的连接描述符配置错误，或者备库的监听器（Listener）没有正确注册远程连接服务，日志传输就会在第一步就失败。
业内专家指出,超过半数的传输故障源于TNS配置的小数点或拼写错误，你可以使用tnsping命令进行初步诊断，在命令行输入tnsping <备库TNS名称>，如果返回的是“OK”，说明网络层基本畅通；如果超时或解析失败，则需检查防火墙策略或DNS解析。
具体操作步骤
- 检查监听状态：在备库服务器上执行
lsnrctl status，确认监听器正在运行，且服务列表中包含了备库的实例名。 - 验证远程连接：在主库服务器上，使用
sqlplus sys/password@<备库TNS名称> as sysdba尝试登录，如果登录成功，说明网络链路和认证配置无误，问题可能出在后续的传输协议上；如果登录失败，请仔细核对listener.ora和tnsnames.ora中的端口、IP和服务名。 - 防火墙策略：确保主库的归档传输端口（默认1521或自定义端口）在防火墙白名单中，不少企业在升级安全策略时，误关了Oracle所需的通信端口。
归档传输协议与参数配置
路通了,还得看“车”对不对，Oracle提供了多种归档传输机制，如ARCH、LGWR、SYNC、ASYNC等，如果参数配置与实际环境不匹配，日志就会“堵”在主库。
LOG_ARCHIVE_DEST_n参数详解
这是控制日志传输的核心参数,你需要确认主库上的LOG_ARCHIVE_DEST_2（假设备库为第二个目的地）是否配置正确。
- SERVICE参数：必须指向备库的TNS名称。
- AFFIRM/NOAFFIRM：生产环境建议使用
AFFIRM，确保日志写入备库磁盘后才确认，防止数据丢失。 - DELAY_MINS：如果设置了延迟应用，需确认是否因延迟导致备库“看起来”没有新日志。
常见配置错误对比
| 错误类型 | 现象描述 | 修正建议 |
|---|---|---|
| SERVICE缺失 | 告警日志提示“ORA-12514: TNS:listener does not currently know of service” | 检查LOG_ARCHIVE_DEST_2中的SERVICE字段是否与备库TNS名称一致 |
| VALID_FOR不匹配 | 主库切换日志时，备库未收到任何日志 | 确认VALID_FOR=(ALL_LOGFILES, ALL_ROLES)或针对当前场景配置正确 |
| REOPEN参数未设 | 网络短暂中断后，传输永久挂起 | 设置REOPEN=300，让Oracle在失败后每隔300秒重试 |
归档目标状态检查
通过SQL查询主库的归档目标状态,可以直观看到传输是否被启用。
SELECT DEST_ID, STATUS, TARGET, ARCHIVED_THREAD#, ARCHIVED_SEQ# FROM V$ARCHIVE_DEST WHERE STATUS != 'INACTIVE';
如果STATUS显示为
VALID，但ARCHIVED_SEQ#不再增长，说明日志已生成但未传输，此时需检查备库的接收服务。
备库接收服务与MRP进程状态
日志传到了备库,备库得“吃”得下去，如果备库的介质恢复进程（MRP, Managed Recovery Process）没有运行，或者备库处于只读打开状态且未启动应用，日志就会堆积在备库的归档目录中，无法应用。
MRP进程监控
在Data Guard环境中，备库必须运行MRP进程才能实时应用日志，你可以使用以下命令检查MRP状态：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
如果查询结果为空,说明MRP进程未启动，你需要手动启动它：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
备库归档目录权限
即使MRP在运行,如果备库的LOG_ARCHIVE_DEST_n指向的磁盘目录权限不足，或者磁盘空间已满，日志写入也会失败。
- 磁盘空间：使用
df -h检查备库归档目录所在分区的使用率，如果空间不足，需清理旧归档或扩容。 - 权限设置：确保Oracle用户（通常是
oracle）对该目录拥有读写权限。
日志应用延迟与数据一致性验证
当传输和应用都正常后,还需确认主备库的数据是否真正同步，日志虽然传过去了，但由于网络抖动或备库负载过高，应用存在较大延迟。
延迟监控指标
通过比较主库和备库的最新归档序列号,可以计算延迟。
- 主库最新序列号：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID=1; - 备库已应用序列号：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES';
如果两者相差较大,说明备库存在积压，此时需检查备库的CPU和IO负载，必要时增加ARCH进程数量以提升传输效率。
数据一致性校验
对于关键业务,建议定期使用DBMS_LOGMNR或第三方工具进行数据块级校验，确保主备库的数据页完全一致，这不仅是排错手段，更是日常运维的最佳实践。
Q&A：归档日志不能自动传送到备库分析
归档日志传送到备库后，备库无法应用怎么办？
首先确认备库是否处于正确的物理备库模式（Physical Standby），如果备库是逻辑备库（Logical Standby），则应用进程为LSP而非MRP，检查备库的STANDBY_FILE_MANAGEMENT参数是否为AUTO，若为MANUAL，主库新建数据文件时备库不会自动创建，导致后续日志应用中断，查看备库告警日志（alert.log），寻找具体的ORA错误码，如ORA-00308（归档文件无法打开）或ORA-19502（写文件错误），根据错误码定位是文件损坏还是权限问题。
主备库之间网络正常，但归档日志传输一直失败，如何快速定位？
启用Oracle的内置诊断功能,在主库上执行ALTER SYSTEM SET LOG_ARCHIVE_TRACE=14;，这将开启详细的日志传输跟踪，随后观察主库的trace目录，查看具体的传输错误信息，在备库上执行SELECT FROM V$DATAGUARD_STATS;，查看transport lag和apply lag的具体数值，如果transport lag持续增长而apply lag为0，说明日志卡在传输环节，重点检查主库的LOG_ARCHIVE_DEST_2配置及网络防火墙；如果两者都增长，说明备库处理不过来，需优化备库性能或增加并行应用进程。
归档日志传输失败是否会影响主库的性能？
这取决于LOG_ARCHIVE_DEST_n的配置，如果配置了OPTIONAL或DELAY，主库生成日志后不会等待备库确认，因此对主库性能影响极小，但如果配置了MANDATORY且未设置AFFIRM，或者备库不可用时主库配置为FAIL，主库在生成归档日志时会阻塞，直到传输成功或超时，这种阻塞会显著增加主库的log file sync等待事件，导致应用响应变慢，生产环境中建议将非关键备库配置为OPTIONAL，或确保网络链路的高可用性，以避免主库性能受损。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/285788.html
