Oracle Data Guard 归档传输故障排查：从报错到根治
在维护Oracle Data Guard环境时，归档日志传输中断是最令人头疼的问题之一。表面上看，无非是网络、参数、状态这几样，但真正卡住你的，往往是一些配置细节上的“失之毫厘”。下面，我们就来系统性地梳理几个典型故障场景及其排查路径。
ORA-16057 根本原因是 LOG_ARCHIVE_DEST_n 中 SERVICE 值与备库 DB_UNIQUE_NAME 不一致，需核对主备库 DB_UNIQUE_NAME、监听器静态注册的 GLOBAL_DBNAME 及是否启用 Standby Redo Logs。
ORA-16057: DGID not found in dataguard configuration
这个报错堪称Data Guard传输启动失败的“招牌”错误。它看似在说配置缺失，但十有八九，问题出在log_archive_dest_n参数里那个service指向的名字，和备库实际的db_unique_name对不上号。
排查时，可以遵循这个清晰的步骤：
- 首先，在主库执行
SELECT DB_UNIQUE_NAME, DATABASE_ROLE FROM V$DATABASE;，确认主库自己的身份标识。 - 接着，在备库执行同样的语句，准确记录下备库的
DB_UNIQUE_NAME。 - 然后，回到主库，查看关键的归档目标参数，例如
SHOW PARAMETER LOG_ARCHIVE_DEST_2。重点核对SERVICE后面跟的是否就是备库的DB_UNIQUE_NAME，千万别把它和INSTANCE_NAME或SERVICE_NAME搞混了。 - 如果发现不匹配，立即用
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db UNIQUE ...' SCOPE=BOTH;这样的语句进行修正（注意替换为你的真实值）。
tnsping 能通但 LGWR 进程无法连接备库服务
很多人会困惑：明明tnsping测试是成功的，为什么归档进程还是连不上？其实，tnsping成功仅仅意味着监听器可达，而LGWR或ARCH进程建立会话，依赖的是监听器里的静态注册信息，具体来说，就是GLOBAL_DBNAME。这个值必须等于备库的DB_UNIQUE_NAME加上DOMAIN_NAME（如果域名默认为空，那它就是DB_UNIQUE_NAME本身）。
连接失败的常见原因包括：
- 备库监听器未配置静态注册：检查
$ORACLE_HOME/network/admin/listener.ora文件，确保里面有类似(SID_DESC = (SID_NAME = orcl)(GLOBAL_DBNAME = standby_db)(ORACLE_HOME = ...))的条目。 - 主库tnsnames.ora配置有误：主库
tnsnames.ora中对应SERVICE的条目，其SERVICE_NAME可能写成了类似orcl这样的实例名，但备库监听器静态注册的却是standby_db，两者对不上。 - 备库状态不对：对于物理备库，必须处于
MOUNT状态才能接收归档，OPEN READ ONLY是不行的；而对于逻辑备库，则需要OPEN并已经启用了SQL Apply。
ARCH 进程报 ORA-12514 或 ORA-12170
遇到ORA-12514，说明监听器收到了请求，但找不到匹配的SERVICE_NAME；而ORA-12170则是连接超时，问题通常出在网络层面。
建议按以下顺序优先排查：
- 测试网络连通性：在主库服务器上，使用
telnet standby_host 1521命令。这能绕过复杂的TNS解析，直接测试到备库监听端口的网络和防火墙情况。 - 确认备库监听器状态：在备库执行
lsnrctl status，查看输出中对应的服务是否显示为READY，并且是否存在Service "standby_db"（或你配置的实际服务名）。 - 检查同步模式与Standby Redo Logs的匹配：查看主库的
LOG_ARCHIVE_DEST_2参数，是否误加了SYNC（同步）或AFFIRM属性？如果用了同步传输，但备库却没有启用Standby Redo Logs（SRL），传输就会卡住并最终超时。 - 临时排除防火墙干扰：可以尝试在备库临时关闭防火墙（例如使用
systemctl stop firewalld），以排除安全策略拦截归档流的可能。记住，归档传输走的是监听端口（如1521），不是数据库实例端口。
传输开启后归档日志不发送，V$ARCHIVE_DEST_STATUS 显示 DEFERRED
有时候，参数配置看起来正确，网络也是通的，但V$ARCHIVE_DEST_STATUS视图里的STATUS字段却长期显示为DEFERRED。这表示Oracle主动暂停了这条归档路径，而且通常不会抛出明显的错误。
此时，需要关注以下几个关键检查点：
- 查看详细的错误信息：执行
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;。有时ERROR列看似为空，但实际上可能隐藏了空格或不可见字符，可以用DUMP(ERROR)函数进一步查看。 - 确认目标状态参数：检查主库的
LOG_ARCHIVE_DEST_STATE_2参数是否被意外设置成了DEFER，而不是ENABLE。用SHOW PARAMETER LOG_ARCHIVE_DEST_STATE_2验证一下。 - 检查备库端的保护机制：备库是否因为应用延迟触发了某些自动保护机制？例如，主库的归档目标参数中如果设置了
MAX_FAILURE或REOPEN间隔不合理，可能导致主库在多次尝试失败后进入静默暂停状态。 - 手动触发测试：尝试手动切换一次归档：
ALTER SYSTEM ARCHIVE LOG CURRENT;，然后立刻再次查询V$ARCHIVE_DEST_STATUS。观察STATUS是否会短暂变为VALID后又变回DEFERRED。如果是这样，那问题大概率出在备库端接收异常，需要立即去查看备库的alert.log日志，寻找紧随其后的ORA-错误。
说到底，很多传输故障的根源，不在于“有没有配置”，而在于“配置的名字对不对得上”，以及“配套的组件（如SRL）有没有准备好”。经验表明，最终卡住问题的，往往是GLOBAL_DBNAME里少了一个下划线，或者STANDBY_FILE_MANAGEMENT参数设成了MANUAL，导致主库新增数据文件时，归档传输被意外设起。细节，才是稳定性的基石。
