DG_CONFIG和DB_UNIQUE_NAME的对应关系是Oracle Data Guard配置中最核心也最容易出错的一环。不少DBA在搭建容灾环境时，参数里的名字随手一写，结果主备之间的日志传输怎么都不通，alert日志里反复出现归档发送失败的记录。这篇文章结合实际配置案例，把两个参数的语义、对应规则和常见报错的排查方法讲清楚。
一、先弄清楚DB_NAME、DB_UNIQUE_NAME和DG_CONFIG各自是什么
很多人把这三个概念混为一谈，实际上它们的层次完全不同。DB_NAME是数据库创建时确定的内部标识，在同一个Data Guard配置中，主库和所有备库的DB_NAME必须相同，因为它们本质上是同一个数据库的不同副本。
DB_UNIQUE_NAME则是区分每个副本的唯一身份。即使主备库的DB_NAME都叫orcl，主库可以叫orcl_pri，备库可以叫orcl_stb。从Oracle 10g开始引入这个参数，就是为了解决同一DB_NAME下多个副本的身份识别问题。每个数据库的DB_UNIQUE_NAME在整套DG环境中必须唯一，并且要在LOG_ARCHIVE_CONFIG的DG_CONFIG属性中全部登记。
DG_CONFIG本质上是一份成员名单，它列出了这个Data Guard配置中所有合法数据库的唯一名。Oracle在传输redo日志时，会用远端的DB_UNIQUE_NAME和这份名单做比对，不在名单里的成员将被拒绝接收日志。一个典型的配置如下：
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(orcl_pri,orcl_stb)'; ALTER SYSTEM SET log_archive_dest_2='SERVICE=orcl_stb LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_stb'; ALTER SYSTEM SET log_archive_dest_state_2=ENABLE;
注意最后一条中的DB_UNIQUE_NAME=orcl_stb，它出现在LOG_ARCHIVE_DEST_N参数里，表示这个目的地对应的数据库身份。这个值必须和远端数据库实际的DB_UNIQUE_NAME完全一致，同时orcl_stb也必须出现在本地的DG_CONFIG名单中，这就是三者之间的核心对应关系。
二、主库、备库、级联备库三种场景下的配置规则
主库这边，LOG_ARCHIVE_DEST_2指向备库服务名，参数中的DB_UNIQUE_NAME写备库的名字，DG_CONFIG中要同时包含主备两边的名字。这是最基础的两节点配置。如果DG_CONFIG里漏掉了备库名字，主库发送日志时会报ORA-16057，提示DG_CONFIG里没有配置该目的地名称。
备库这边也不能偷懒。备库同样要设置LOG_ARCHIVE_CONFIG，且DG_CONFIG内容与主库保持一致。此外备库通常还会为角色切换做准备，配置一个指向主库的LOG_ARCHIVE_DEST_2，这样一旦切换为主库角色，就能立即向原主库发送日志。参数里的VALID_FOR子句就是干这个用的：
-- 备库上的配置，为switchover做准备 ALTER SYSTEM SET log_archive_dest_2='SERVICE=orcl_pri LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_pri';
级联备库（cascade standby）场景下容易出错。假设架构是主库orcl_pri向一级备库orcl_stb1发送日志，orcl_stb1再转发给级联备库orcl_stb2。此时orcl_stb1上的LOG_ARCHIVE_DEST_2要指向orcl_stb2，DB_UNIQUE_NAME写orcl_stb2，而三个数据库的DG_CONFIG都必须包含全部三个名字。漏写任何一个，日志链路就会断在那一环。建议的做法是把DG_CONFIG写成统一模板，在所有成员上保持完全一致，这样既方便维护，也避免角色切换后出现名单不全的问题。
三、配置不对应时的典型报错与排查方法
最常见的是ORA-16057。alert日志中的完整信息通常是归档日志不可用或者直接提示目的地名称未在DG_CONFIG中注册。看到这个错误，第一件事是检查show parameter log_archive_config的输出，确认目的地的DB_UNIQUE_NAME是否真的在名单里。注意DG_CONFIG对名字大小写不敏感，但对拼写敏感，名字拼错就必然失败。
第二个排查利器是动态性能视图。V$ARCHIVE_DEST的STATUS列能直观反映目的地状态，VALID表示正常，ERROR表示发送失败，DEFERRED表示被手动挂起。配合V$ARCHIVE_DEST_STATUS可以进一步看到发送的日志序列号和错误信息。一个健康的目的地查询结果应该类似这样：
SELECT dest_id, status, destination, error FROM v$archive_dest WHERE dest_id <= 10; -- 正常情况下输出： -- DEST_ID STATUS DESTINATION ERROR -- ------- --------- ------------------ -------- -- 1 VALID USE_DB_RECOVERY_FILE_DEST -- 2 VALID orcl_stb
如果STATUS列是ERROR，同时ERROR列出现ORA-12154之类的网络错误，那是TNS服务名解析问题；如果出现ORA-16057或ORA-16058，基本可以断定是DB_UNIQUE_NAME与DG_CONFIG的对应关系出了问题。另外可以查V$DATAGUARD_CONFIG视图，它会列出当前DG_CONFIG中登记的所有唯一名以及每个数据库自己的DB_UNIQUE_NAME，两边对照一眼就能看出名单是否完整、名字是否一致。
还有一个隐蔽的坑：远端数据库的DB_UNIQUE_NAME与本地参数里写的不一致。比如RMAN复制的备库忘了改DB_UNIQUE_NAME，仍然和主库同名，此时本地参数里写的名字在远端根本对不上。解决办法是在备库上执行ALTER SYSTEM SET db_unique_name='orcl_stb' SCOPE=SPFILE后重启实例，再重新核对DG_CONFIG名单。搞清楚这条链路——目的地参数里的名字等于远端实际DB_UNIQUE_NAME，且该名字必须在本DG_CONFIG名单中——Data Guard的日志传输问题就排除了大半。
DG_CONFIGDB_UNIQUE_NAMEOracle Data Guard修改时间：2026-09-03 18:03:12