ORA-16057是因主备库log_archive_config参数配置不一致导致的硬性校验失败，需严格比对大小写、空格、括号、逗号及db_unique_name拼写，修改后须重置LOG_ARCHIVE_DEST_STATE_n并重启MRP进程。
ora-16057 不是网络或监听问题，而是主备库的 log_archive_config 配置不一致导致的硬性校验失败。
查主备库 log_archive_config 是否完全一致
这个参数必须在主库和备库上都显式配置，且内容严格相同：大小写、空格、括号、逗号全部要对得上。常见错误包括：
- 主库配了
dg_config=(prim,stan)，备库漏配或配成dg_config=(PRIM,STAN)（大小写不一致） - 主库有空格如
dg_config= (prim, stan)，备库没空格，Oracle 会认为这是两个不同字符串 - 备库还残留旧 DG 配置，比如之前搭过另一套 DG，
spfile里还存着dg_config=(old1,old2) - 用
SHOW PARAMETER log_archive_config看到值为NULL或空，说明该库根本没设这个参数
确认 db_unique_name 是否拼写准确且全局唯一
log_archive_config 里列出的每个名字，必须和对应库的 db_unique_name 完全一致（不是 db_name，也不是 service_name）。检查方式：
- 主库执行：
SELECT NAME, DB_UNIQUE_NAME FROM V$DATABASE; - 备库执行同样语句，对比输出
- 如果备库显示的是
DB_UNIQUE_NAME为standby_old，但主库log_archive_config写的是standby_new，就必然报ORA-16057 - 特别注意：RAC 环境下每个实例的
db_unique_name必须统一，不能按实例名区分
改完参数后必须重新启用归档目标
只改 log_archive_config 不够，LOG_ARCHIVE_DEST_STATE_n 需要重置才能触发重协商：
- 先在主库执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER; - 等几秒，再执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; - 不要跳过
DEFER步骤——直接ENABLE可能沿用旧状态缓存，不生效 - 执行后立刻查
V$ARCHIVE_DEST_STATUS的ERROR列，应为空；STATUS应变为VALID
备库也要重启 MRP 才能同步新配置
主库改完只是“发得出去”，备库得“收得进来”。如果备库 RECOVERY_MODE 是 IDLE，说明 MRP 进程没跑：
- 确保备库处于
MOUNT状态（非OPEN） - 执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; - 再查
V$MANAGED_STANDBY，确认PROCESS=MRP0且STATUS=APPLYING_LOG - 如果报错
ORA-16047: DGID mismatch，说明log_archive_config还没真正对齐，得回头再核对一遍
最易被忽略的一点：log_archive_config 是静态参数，但修改后无需重启实例——可在线生效；然而，它只影响后续归档传输行为，对已卡住的归档序列无修复能力。所以一旦看到 ORA-16057，第一反应永远是比对主备两库该参数的原始字符串，而不是去动监听或 TNS 名。
