Ora-16047 of a DG environment: dgid mismatch between destination setting and target database troubleshooting and listening vncr features

DG Environment is now a common infrastructure , The overall architecture is mature and stable , It has been the routine implementation project of the company . In the near future , A colleague asked a question ,DG When it's set up , Report errors ORA-16047: DGID mismatch between destination setting and target database. This error report looks like DGID Mismatch , Usually configure log_archive_config='DG_CONFIG Parameters can be ; This troubleshooting found that , This parameter is set normally , Why is there still such a problem ？

Next, based on DG Starting from the configuration principle of , Check this problem step by step ：

1. According to the report , see log_archive_config='DG_CONFIG Parameters , Check the master 、 Standby node DB_UNIQUE_NAME; The configuration is normal .

2. No problem was found in the previous step ; This is based on DG Transmission principle of , Is based on DG Transmission parameters such as log_archive_dest_2 Specified by the value in ; Then analyze the value of this parameter , This time is SERVICE=HZDBRAC LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=HZDBRAC'

3. about log_archive_dest_2 Parameters ,SERVICE=HZDBRAC adopt tnsnames.ora Specifies the information of the standby machine （IP、 port 、SERVICE_NAME）, as well as DB_UNIQUE_NAME. Check at the master node , The format is correct .

4. Check the standby configuration , When viewing the listening configuration , Exception found ：RAC To stand-alone environment , Monitor the program serviceK Three database instances appear ;

[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 To stand-alone environment , Three database instances appear ？
  Instance "HZDB1", status READY, has 1 handler(s) for this service...
  Instance "HZDB2", status READY, has 1 handler(s) for this service...

5. The problem summary ： Check the listening log , It can be found that it is a standby machine , Use... When building RAC The parameter of is not deleted when it is modified remote_listener Parameters , As a result, the instance of the standby machine is also registered to RAC Environmental Science , And in line SERVICE Of the 1 individual ; In this way, the single machine is switching to the primary node , towards RAC( For the node ） Data transfer , It will appear that on the surface, it will eventually connect ：log_archive_dest_2 Of SERVICE=HZDBRAC Even the RAC, Actually, it bypasses the connection to the local machine . So appear ORA-16047: DGID mismatch between destination setting and target database A mismatch is reported as an error .

Modify parameters on a single machine alter system set remote_listener=''; after , again ENABLE Log transfer parameters , Back to normal . This also shows that listening VNCR It is still necessary to set the feature , Otherwise, it may be attacked by misoperation and affect normal business ！！