ora-16047 表明 db_unique_name 冲突，需立即修正：主备库 db_unique_name 必须一致，且 log_archive_dest_2 中配置、控制文件、密码文件、ocr（rac）、tnsnames/listener/rman/broker 等均需同步更新。
ora-16047 是 db_unique_name 冲突的明确信号，必须立刻修正，否则日志传输完全中断。
确认 db_unique_name 冲突的具体表现
主库无法推送归档到备库，最直接的现象是主库告警日志中反复出现 ORA-16047: DGID mismatch between destination setting and target database；同时 PING[ARC2]: Heartbeat failed to connect to standby 'xxx' 会持续报错。备库侧通常伴随 ORA-00313、ORA-00312 等日志组打开失败，本质是 LGWR 尝试写入 standby redo 时因身份校验失败被拒绝。
- 先在主库查：
SELECT NAME, DB_UNIQUE_NAME FROM V$DATABASE; - 再在备库查同一条语句，对比输出是否一致
- 检查主库
LOG_ARCHIVE_DEST_2参数中的DB_UNIQUE_NAME值（如ALTER SYSTEM SHOW PARAMETER LOG_ARCHIVE_DEST_2），是否与备库实际的DB_UNIQUE_NAME匹配
单实例 DG 环境下修改 db_unique_name 的正确步骤
不能只改参数，也不能在线改完就完事——必须确保控制文件、密码文件、监听/tnsnames 配置三者同步更新，否则后续连接或启动会失败。
- 在备库执行：
ALTER SYSTEM SET db_unique_name = 'new_dg_name' SCOPE=SPFILE;（例如从dg1改为dg2） - 关闭备库：
SHUTDOWN IMMEDIATE，再用STARTUP MOUNT启动（此时控制文件仍含旧名，但 SPFILE 已更新） - 执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;（确保无恢复进程挂住） - 重启数据库：
SHUTDOWN IMMEDIATE; STARTUP—— 这一步会真正将新db_unique_name写入控制文件 - 验证：
SELECT DB_UNIQUE_NAME FROM V$DATABASE;必须返回新值
RAC 环境下额外必须处理的 OCR 和密码文件项
12c+ RAC 中，db_unique_name 不仅存在于数据库内部，还注册在集群资源层。只改数据库参数会导致 ORA-01017: invalid username/password 这类看似密码错误、实为身份不匹配的问题。
- 用
srvctl config database -d <db_unique_name></db_unique_name>查当前注册名，确认是否与数据库内一致 - 若不一致，先停库：
srvctl stop database -d old_name - 修改 OCR 记录：
srvctl modify database -d old_name -n new_name - 更新密码文件路径（尤其当使用 ASM 存储时）：
srvctl modify database -d new_name -pwfile +DATA/new_name/PASSWORD/pwdnew_name - 最后重新注册并启动：
srvctl add database -d new_name ...（补全必要参数），再srvctl start database -d new_name
修改后必须同步检查的外围配置
很多人改完数据库就以为结束了，结果第二天发现 DG 又断了——因为这些地方没跟着改：
-
tnsnames.ora中每个CONNECT_DATA下的SERVICE_NAME或DB_NAME虽然可以不同，但tns alias名称本身常被脚本硬编码，建议统一命名逻辑 -
listener.ora中的GLOBAL_DBNAME应设为db_unique_name（不是db_name），否则远程连接可能路由到错误实例 - RMAN 的
CONFIGURE DB_UNIQUE_NAME需同步更新，例如：CONFIGURE DB_UNIQUE_NAME 'new_name' CONNECT IDENTIFIER 'tns_alias'; - 如果用了 Data Guard Broker，
DGMGRL中的配置也要用EDIT DATABASE ... SET PROPERTY 'DbUniqueName'='new_name'手动修正
最关键的细节是：修改 db_unique_name 后，所有依赖该名称的自动化脚本、监控项、备份策略都得人工核对一遍——它不像改个表名那样局部生效，而是牵一发而动全身的身份标识。
