DG环境的现在已经是一个基础常见的架构，整体架构成熟稳定，已经是公司的常规实施项目。近期，同事转来一个问题，DG搭建好后，报错ORA-16047: DGID mismatch between destination setting and target database。 这个报错看起来是DGID不匹配，通常配置log_archive_config='DG_CONFIG参数即可；本次问题排查发现，此参数设置正常，为何仍有此问题？
接下来基于DG的配置原理出发，一步步排查此问题：
1.根据报错，查看log_archive_config='DG_CONFIG参数，检查主、备节点的DB_UNIQUE_NAME；配置正常。
2.上一步排查没发现问题；此时基于DG的传输原理，是基于DG的传输参数如 log_archive_dest_2中的值来指定的；那么来分析此参数的值，本次为SERVICE=HZDBRAC LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=HZDBRAC'
3.对于 log_archive_dest_2参数，SERVICE=HZDBRAC通过tnsnames.ora指定了备机的信息（IP、端口、SERVICE_NAME），以及DB_UNIQUE_NAME。在主节点检查，格式无误。
4.检查备机配置，查看监听配置时，发现异常：RAC到单机环境，监听程序的serviceK出现三个数据库实例；
[grid@rac11g02 ~]$ lsnrctl status listener_scan1
LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 24-FEB-2022 14:44:45
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))
STATUS of the LISTENER
------------------------
Alias LISTENER_SCAN1
Version TNSLSNR for Linux: Version 11.2.0.4.0 - Production
Start Date 23-FEB-2022 12:19:12
Uptime 1 days 2 hr. 25 min. 32 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/11.2.0/grid/network/admin/listener.ora
Listener Log File /u01/11.2.0/grid/log/diag/tnslsnr/rac11g02/listener_scan1/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN1)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.3.105)(PORT=1521)))
Services Summary...
Service "HZDB" has 3 instance(s).
Instance "HZDB", status READY, has 1 handler(s) for this service... ===>>>RAC到单机环境，出现三个数据库实例？
Instance "HZDB1", status READY, has 1 handler(s) for this service...
Instance "HZDB2", status READY, has 1 handler(s) for this service...5.问题总结：检查监听日志，可以发现是备机，在搭建时使用RAC的参数修改时未删除remote_listener参数，导致备机的实例也注册到了RAC环境，并且排在SERVICE的第1个；这样单机在切换为主节点，向RAC(备节点）传输数据时，就会出现表面上看最终要连：log_archive_dest_2的SERVICE=HZDBRAC连的是RAC，实际又绕回连接本机。所以出现ORA-16047: DGID mismatch between destination setting and target database不匹配报错。
在单机上修改参数alter system set remote_listener='';后，重新ENABLE日志传输参数后，恢复正常。这也说明监听的VNCR特性还是有必要设置的，不然可能会被误操作攻击影响正常业务！！
原文链接：https://blog.csdn.net/haibusuanyun/article/details/123524317
