connect identifier连不上是broker操作首要障碍，必须用含用户名、密码及db_unique_name的tns服务名连接，且该服务名对应监听器中注册的db_unique_name_dgmgrl；报ora-12154需查tnsnames.ora条目与隐藏空格，报ora-12170则须确认监听端点加载与网络连通性。
CONNECT IDENTIFIER连不上就别往下走
所有 Broker 操作卡在第一步，基本都是 dgmgrl 连不上主库或备库。它不认默认实例，也不走操作系统认证，必须显式带用户名、密码和 DB_UNIQUE_NAME。
常见错误包括：
- 直接敲
dgmgrl回车，结果连的是本地默认实例（可能压根不是 DG 环境里的库） - 用
dgmgrl /试图走 OS 认证，但没切到oracle用户，或数据库未启用REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE -
CONNECT IDENTIFIER写成服务名（SERVICE_NAME）或实例名（INSTANCE_NAME），实际应是tnsnames.ora中定义的、能连通对方库的网络服务名，且该服务名对应的GLOBAL_DBNAME必须为db_unique_name_DGMGRL
报 ORA-12154？检查 $ORACLE_HOME/network/admin/tnsnames.ora 是否存在对应条目，语法是否正确（尤其注意 HOST 值前后、SERVICE_NAME 末尾的隐藏空格，可用 cat -A tnsnames.ora 查看）；报 ORA-12170？说明监听器根本没响应，先 lsnrctl status 看端点是否加载了目标服务，再确认防火墙、路由、SELinux 是否拦截。
CREATE CONFIGURATION前必须人工核对的三处参数
Broker 不会帮你校验底层配置是否合理，只按参数值做字面匹配。CREATE 失败几乎全是这三项没对齐：
-
DB_UNIQUE_NAME：主备库都必须已设置，且互不相同；查法：SHOW PARAMETER db_unique_name；大小写敏感，不能是默认的ORCL -
LOG_ARCHIVE_CONFIG：必须显式包含双方的DB_UNIQUE_NAME，例如'DG_CONFIG=(pri,sto)'；缺一个就报ORA-16625: cannot reach database -
LOG_ARCHIVE_DEST_2（或更高编号）：主库上该参数必须指向备库，且含DB_UNIQUE_NAME=sto（值必须和备库实际的DB_UNIQUE_NAME完全一致）、VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)、SYNC/ASYNC明确指定；漏掉DB_UNIQUE_NAME是高频坑
另外，主库必须 OPEN，备库必须 MOUNT（不能是 READ ONLY），否则命令直接拒绝。
ENABLE CONFIGURATION卡住或报 ORA-16792 怎么办
ENABLE 不是瞬间完成的操作，Broker 会逐项检查资源状态。卡住或报错，说明某项依赖未就绪，而不是命令写错了。
最常见原因：
- 备库归档模式关闭：
ARCHIVE LOG LIST显示Archive Mode: Disabled—— Broker 强制要求主备都开启归档，哪怕你用实时应用（REAL-TIME APPLY） - 备库状态不对：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE返回PHYSICAL STANDBY+MOUNTED才合法；如果是READ ONLY，需先SHUTDOWN IMMEDIATE再STARTUP MOUNT - 属性不一致：
SHOW DATABASE VERBOSE 'standby_db_name'若提示ORA-16792: configurable property value is inconsistent with database setting，说明 Broker 配置的某个属性（如LogArchiveFormat）和数据库实际参数值不符，需用EDIT DATABASE ... SET PROPERTY同步
执行 VALIDATE DATABASE 'standby_db_name' 能快速定位具体哪一项失败，比盲猜高效得多。
ORA-16532 看似监听故障，实则是 Broker 元数据断裂
ORA-16532 的典型表现是 dgmgrl 连不上、SHOW CONFIGURATION 卡死或报错，但 tnsping 和 lsnrctl status 都正常——这不是监听器问题，而是 Broker 配置本身丢失或损坏。
快速验证步骤：
- 查
SHOW PARAMETER dg_broker_start，若返回FALSE，Broker 根本没启用，dgmgrl必然失败 - 检查
$ORACLE_HOME/dbs/dr1*.dat文件是否存在且非空；若被删或为空，broker 配置已物理丢失 - 主库查
V$DATAGUARD_CONFIG，若只返回LOCAL或无结果，说明 broker 视图已失效；备库查V$MANAGED_STANDBY，若MRP0进程状态为APPLYING_LOG，说明物理同步还在跑，只是 broker 层断了
重建前务必确保：主备库 DG_BROKER_START=TRUE 已生效且数据库重启过；主库 LOG_ARCHIVE_DEST_2 中的 DB_UNIQUE_NAME 值，和备库实际的 DB_UNIQUE_NAME 完全一致（大小写敏感）；LOCAL_LISTENER 指向的地址必须可达，不能是 localhost。
