ora-16047 的直接诱因是备库 db_unique_name 与主库 log_archive_dest_n 中配置值不一致，且备库未正确设置 log_archive_config；必须修改备库 db_unique_name 并写入 spfile 后重启，同时在备库配置含所有 dg 实例的 log_archive_config。
确认备库 DB_UNIQUE_NAME 是否与主库配置一致
ORA-16047 的直接诱因通常是主库 LOG_ARCHIVE_DEST_n 中设置的 DB_UNIQUE_NAME 值，和备库实际的 DB_UNIQUE_NAME 不匹配。这不是大小写问题，而是字符串完全一致才通过校验。
- 在备库执行：
SELECT DB_UNIQUE_NAME FROM V$DATABASE;，记下返回值 - 在主库执行：
SHOW PARAMETER LOG_ARCHIVE_DEST_2（或对应目标编号），检查db_unique_name=xxx后面的值 - 若不一致，必须修改备库：执行
ALTER SYSTEM SET DB_UNIQUE_NAME='xxx' SCOPE=SPFILE;，然后SHUTDOWN IMMEDIATE+STARTUP MOUNT - 注意：仅
SCOPE=BOTH不生效，必须写入 SPFILE 并重启；OPEN状态下无法修改该参数
检查备库是否设置了 log_archive_config
很多 DBA 只配主库的 log_archive_config，却忽略备库也要配——这是 ORA-16047 最常被漏掉的一环。11g 要求主备双方都明确声明彼此在 DG 配置中的身份，否则 DGID 校验直接失败。
- 在备库执行：
SHOW PARAMETER log_archive_config，若返回空或DG_CONFIG=()，就是问题所在 - 正确配置应包含所有参与 DG 的实例，例如：
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(primary_db,standby_db)' SCOPE=BOTH; - 该参数无需重启，但必须确保备库的
DB_UNIQUE_NAME已在列表中，且拼写、大小写、引号（不加）全部一致 - 若备库是 RAC，需加
SID='*'保证所有实例生效
验证归档目标状态和错误详情
V$ARCHIVE_DEST_STATUS 是第一手诊断入口，不能只看 STATUS=ERROR，要结合 ERROR 列和 V$ARCHIVE_DEST 的原始配置交叉印证。
- 在主库运行：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; - 若 ERROR 显示
DGID mismatch，基本锁定是上述两个参数问题；若显示ORA-12514或ORA-16057，说明 TNS 或 DG_CONFIG 根本没生效 - 再查：
SELECT DEST_ID, DESTINATION, BINDING, VALID_FOR, DATABASE_MODE FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;，确认VALID_FOR是否含(ONLINE_LOGFILES,PRIMARY_ROLE)，避免角色错配导致静默失效 - 别跳过告警日志：搜索主库
alert_<sid>.log</sid>中最近 10 分钟的ORA-16047和FAL request rejected，它们往往连带出现
排除版本与补丁不一致的干扰
虽然 ORA-16047 表面是配置错误，但如果备库小版本或 PSU 补丁与主库不一致，MRP0 进程可能根本起不来，导致主库误判为“目标不可达”，进而触发 DGID 校验失败。
- 在主备库分别执行：
SELECT BANNER FROM V$VERSION WHERE BANNER LIKE 'Oracle%';，比对完整字符串（如11.2.0.4.0vs11.2.0.4.190115） - 运行：
$ORACLE_HOME/OPatch/opatch lsinventory -detail，确认 RDBMS 和 Network 组件补丁集完全一致 - 在备库查：
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';，若无结果或 STATUS 为NOT ACTIVE，大概率是版本冲突，不是 DGID 问题 - 此时看备库 alert.log，搜
control file version mismatch或incompatible database version，就能一锤定音
备库参数配置是 ORA-16047 的核心战场，但真正难排查的是它和版本不一致、非 SPFILE 启动、RAC 实例未同步配置等场景交织在一起。比如备库用 PFILE 启动时，log_archive_config 修改后看似生效，实则只作用于当前实例，下次重启就丢失——这种细节不翻 alert.log 和 SELECT VALUE FROM V$PARAMETER 对比，很容易绕圈子。
