主备库DB_UNIQUE_NAME必须不同，否则DG同步失效；需检查主备库参数、归档配置及tnsnames.ora中service名是否匹配，单机/RAC修改时须严格按步骤操作并同步更新LOG_ARCHIVE_CONFIG和LOG_ARCHIVE_DEST_2。
主备库 DB_UNIQUE_NAME 不能相同，否则 LOG_ARCHIVE_DEST_2 归档根本不会发出去，DG 同步直接失效 —— 这不是配置问题，是 Oracle 的硬性校验逻辑。
ORA-16642 或归档卡在 LOG_ARCHIVE_DEST_2 怎么确认是 DB_UNIQUE_NAME 冲突
这类错误本质是主备身份混淆，常见现象包括：
- 执行
DGMGRL> add database报ORA-16642: DB_UNIQUE_NAME mismatch - 主库
V$ARCHIVE_DEST.STATUS显示ERROR，ERROR列内容为ORA-16057: DGID from server not in Data Guard configuration - 备库告警日志反复出现
ARC0: Failed to connect to destination LOG_ARCHIVE_DEST_2，但tnsping和密码文件都正常 - 主库
SHOW PARAMETER db_unique_name和LOG_ARCHIVE_CONFIG中列出的名称不一致（比如主库设了DB_UNIQUE_NAME=orcl，但LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcl)'）
立刻查三处：
- 主库：
SHOW PARAMETER db_unique_name、SHOW PARAMETER log_archive_config、SELECT DEST_ID, DESTINATION, DB_UNIQUE_NAME FROM V$ARCHIVE_DEST WHERE DEST_ID = 2 - 备库：同样查这三项，重点比对
DB_UNIQUE_NAME值是否和主库重复、大小写是否完全一致 - 两边
$ORACLE_HOME/network/admin/tnsnames.ora中对应 service 名是否指向正确的DB_UNIQUE_NAME（不是DB_NAME）
单机库改 DB_UNIQUE_NAME 的关键动作和陷阱
单机环境没 CRS 干预，但参数是静态的，改错一步就启不动库：
- 必须用
ALTER SYSTEM SET db_unique_name=newname SCOPE=SPFILE——MEMORY或BOTH无效，重启后会回退 - 改完立刻验证 SPFILE 是否真被更新：
strings $ORACLE_HOME/dbs/spfile$ORACLE_SID.ora | grep db_unique_name，别只信 SQL*Plus 输出 - 如果 SPFILE 在 ASM 里，得先连
sqlplus / as sysdba执行CREATE PFILE FROM SPFILE，再用strings检查生成的 pfile - 关库后必须用
STARTUP MOUNT（不是 OPEN），否则可能报ORA-01102: cannot mount database in EXCLUSIVE mode—— 因为控制文件里还存着旧名 - 启动后立即查
SELECT NAME, DB_UNIQUE_NAME FROM V$DATABASE，确保和SHOW PARAMETER db_unique_name一致
RAC 环境下改 DB_UNIQUE_NAME 必须走 srvctl 三步法
RAC 的 db_unique_name 是 CRS 资源名，SQL 直接改会触发 ORA-65500: could not modify db_unique_name, resource exists。顺序错了就卡死：
- 第一步：停库并彻底移除集群资源 —— 先
srvctl stop database -d oldname，再srvctl remove database -d oldname -f（不加-f会提示资源正被使用） - 第二步：改 SPFILE 参数 —— 用 SQL*Plus 连任一实例（此时库是 DOWN 状态），执行
ALTER SYSTEM SET db_unique_name=newname SCOPE=SPFILE - 第三步：重新注册资源 ——
srvctl add database -d newname -o $ORACLE_HOME -p +DATA/newname/PARAMETERFILE/spfile.ora -s PRIMARY -t OPEN -e NONE；如果密码文件也在 ASM，还得同步替换：orapwd file=+DATA/newname/PASSWORD/pwdboston format=y，再用srvctl modify database -d newname -pwfile +DATA/newname/PASSWORD/pwdboston - 切记：
srvctl config database -d newname输出的Spfile路径必须和你srvctl add时指定的完全一致，否则启库时报PRCR-1001: Resource ora.newname.db does not exist
改完 DB_UNIQUE_NAME 后 LOG_ARCHIVE_CONFIG 和 LOG_ARCHIVE_DEST_2 必须同步更新
很多人只改了 db_unique_name，忘了配套改归档参数，结果还是不同步：
- 主库
LOG_ARCHIVE_CONFIG必须包含主备双方的DB_UNIQUE_NAME，格式为'DG_CONFIG=(primary_name,standby_name)'，顺序无关，但名称必须和各自库上SHOW PARAMETER db_unique_name输出严格一致（含大小写） - 主库
LOG_ARCHIVE_DEST_2的DB_UNIQUE_NAME子句必须填备库的DB_UNIQUE_NAME，例如：'SERVICE=stdby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby' - 备库同理：
LOG_ARCHIVE_DEST_2的DB_UNIQUE_NAME必须填主库的DB_UNIQUE_NAME，且LOG_ARCHIVE_CONFIG也要双向包含 - 所有
LOG_ARCHIVE_DEST_n对应的LOG_ARCHIVE_DEST_STATE_n必须是ENABLE，否则参数设对了也白搭
最常被忽略的是大小写和空格 —— DB_UNIQUE_NAME=STDBY 和 DB_UNIQUE_NAME=stdby 在 Oracle 看来是两个库，DG_CONFIG=(A,B ) 末尾多一个空格也会导致 ORA-16057。
