ora-16047错误本质是主备库dgid校验失败，根源在于log_archive_config和db_unique_name配置未严格匹配；需确保备库db_unique_name与主库归档目标中指定值一致，并双向配置完整dg_config列表。
ORA-16047 错误本质是主备库之间 DGID 校验失败，不是网络不通或权限不足，而是配置层面的信任关系没对齐。只要主备两端的 log_archive_config 和 db_unique_name 严格匹配，问题基本就解了。
检查备库的 db_unique_name 是否正确
这是最常见、最直接的触发点。备库如果沿用主库的 db_unique_name，主库在发日志时会拒绝它——因为 DGID 是基于该值生成并校验的。
- 在备库执行：
SELECT DB_UNIQUE_NAME FROM V$DATABASE;，确认返回值与主库LOG_ARCHIVE_DEST_n中指定的db_unique_name=xxx完全一致（注意大小写） - 若不一致，不能直接用
ALTER SYSTEM SET db_unique_name=...修改（尤其在 RAC 环境下会报ORA-65500），必须改 SPFILE 并重启：ALTER SYSTEM SET db_unique_name='standby1' SCOPE=SPFILE; - 19c RAC 备库还需额外处理集群资源：先用
srvctl remove database -d <old_name></old_name>移除旧资源，再用新db_unique_name重建数据库资源
确保主备库都设置了完整的 log_archive_config
11g 及以后版本要求主备双方都显式配置该参数，只在主库配、备库不配，或配得不全（漏掉某个备库名），都会导致 DGID 不被认可。
- 主库和备库都要执行：
SHOW PARAMETER log_archive_config - 正确值应类似：
DG_CONFIG=(primary1,standby1,standby2)，括号内包含所有参与 DG 的库名，顺序无关，但拼写、大小写必须完全一致 - 修改后立即生效：
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(...)' SCOPE=BOTH;；RAC 环境建议加SID='*' - 特别注意：空值、
'DG_CONFIG=()'或只写一个名字，都等同于未配置，会触发 ORA-16047
验证归档目标状态与错误来源
别只看主库告警日志里的 PING[ARC2]: Heartbeat failed...，要定位到具体哪个归档目标出问题，以及错在哪一端。
- 主库查：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE STATUS != 'VALID';，找到报ORA-16047的DEST_ID - 顺着这个
DEST_ID查对应配置：SELECT DEST_NAME, DESTINATION, VALUE FROM V$ARCHIVE_DEST WHERE DEST_ID = X;，重点核对其中db_unique_name=xxx部分 - 去备库检查监听是否真能连上（用
tnsping <service_name></service_name>），但优先排查配置而非网络——因为 ORA-16047 是校验阶段失败，根本还没走到建连接那步
RAC 环境下密码文件与 ASM 路径需同步更新
19c RAC 备库改完 db_unique_name 后，如果不更新密码文件和集群资源配置，即使参数对了，LGWR 进程仍会因认证失败而报 ORA-16047。
- 新
db_unique_name对应的密码文件必须存在且有效：从 ASM 拷出原密码文件，重命名（如pwdstandby1.256.12345），再传回 ASM 对应路径 - 确认
spfile路径已更新：SHOW PARAMETER spfile，确保指向新db_unique_name下的文件（如+DATA/STANDBY1/PARAMETERFILE/spfile.280.1135195669） - 重启前用
srvctl config database -d standby1验证集群中该数据库资源的Database unique name已更新
真正容易被忽略的是：备库也必须参与 DG 信任链构建。很多人以为“主库配好就行”，结果备库静默不响应，主库反复重试直到超时并记入 ORA-16047。配置不是单向设置，而是双向握手。
