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 - 在备库同样执行该语句，记录其
DB_UNIQUE_NAME - 在主库查
SHOW PARAMETER LOG_ARCHIVE_DEST_2（假设用的是 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 成功只说明监听器可达，不代表 Data Guard 归档进程能真正建立会话。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中对应SERVICE的条目，其SERVICE_NAME值写成了orcl或orcl.example.com，但备库监听器注册的是standby_db - 备库未启动到
MOUNT状态：物理备库必须处于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"（或你配置的值）存在 - 检查主库
LOG_ARCHIVE_DEST_2是否误加了SYNC或AFFIRM，而备库未启用 Standby Redo Logs（SRL）：缺少 SRL 会导致 SYNC 传输卡住并最终超时 - 临时关闭备库防火墙测试（如
systemctl stop firewalld），排除策略拦截归档流（注意：归档传输走的是监听端口，不是数据库实例端口）
传输开启后归档日志不发送，V$ARCHIVE_DEST_STATUS 显示 DEFERRED
即使参数配置正确、网络通畅，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 导致新增数据文件时归档传输被挂起。
