dgmgrl必须显式指定用户名密码和db_unique_name连接主备库，否则默认连本地实例或认证失败；CREATE CONFIGURATION前须确认DB_UNIQUE_NAME、LOG_ARCHIVE_CONFIG、LOG_ARCHIVE_DEST_2等参数正确且主库OPEN、备库MOUNT；ENABLE CONFIGURATION前需VALIDATE DATABASE并确保归档开启、监听正常、时间同步。
怎么用 dgmgrl 连上主库和备库
连不上就什么都做不了，dgmgrl 默认不带身份认证，必须显式指定用户名密码和连接方式。常见错误是直接敲 dgmgrl 回车，结果连的是本地默认实例（可能根本不是dg环境里的库），或者用操作系统认证（/）但没切到 oracle 用户。
- 主库侧必须用具有
SYSDBA权限的用户连接，推荐：dgmgrl sys/<i>password</i>@<i>primary_db_unique_name</i> - 备库同理，但注意：
db_unique_name要和init.ora或 SPFILE 里配置的一致，不是服务名（service_name）或实例名（instance_name） - 如果报错
ORA-12154: TNS could not resolve the connect identifier，说明tnsnames.ora缺失或条目名写错了，检查$ORACLE_HOME/network/admin/tnsnames.ora是否包含对应条目且语法正确
执行 CREATE CONFIGURATION 前必须确认什么
这一步失败率极高，不是语法问题，而是环境前提没满足。Broker 不会帮你校验底层配置，它只认参数值是否匹配预期。
-
DB_UNIQUE_NAME必须在两库中都已设置，且不能重复；查法：SHOW PARAMETER db_unique_name -
LOG_ARCHIVE_CONFIG必须包含双方的DB_UNIQUE_NAME，例如：'DG_CONFIG=(pri,sto)'—— 缺一个就报ORA-16625: cannot reach database -
LOG_ARCHIVE_DEST_2（或更高编号）必须指向备库，且SYNC/ASYNC、VALID_FOR、DB_UNIQUE_NAME都得对得上；漏掉DB_UNIQUE_NAME=sto是高频坑 - 主库必须处于
OPEN状态，备库必须是MOUNT（非READ ONLY），否则CREATE CONFIGURATION直接拒绝
ENABLE CONFIGURATION 卡住或报 ORA-16792 怎么办
启用配置不是原子操作，Broker 会逐项检查资源状态。卡住往往意味着某项依赖未就绪，而不是命令本身有问题。
- 最常见是备库的
ARCHIVE LOG LIST显示Archive Mode: Disabled—— Broker 要求主备都必须归档模式，哪怕你用的是实时应用（REAL-TIME APPLY） - 检查
SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE FROM V$DATABASE;，确保主库是PRIMARY、备库是PHYSICAL STANDBY；如果备库是READ ONLY，先SHUTDOWN IMMEDIATE再STARTUP MOUNT - ORA-16792 通常伴随具体子错误，比如
ORA-16810: multiple errors or warnings detected for database，这时立刻运行SHOW DATABASE VERBOSITY查明细 - 别跳过
VALIDATE DATABASE：启用前手动跑一遍，比盲启快得多
初始化后第一个 SWITCHOVER 失败的典型原因
很多人以为配完 Broker 就能无缝切换，结果第一次 SWITCHOVER 就挂，其实问题出在“初始化完成”不等于“状态同步完成”。
- 主库
ARCHIVE LOG CURRENT后，必须等备库SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES';追平主库当前日志序号，否则SWITCHOVER报ORA-16470 - 检查
SELECT STATUS, INSTANCE_NAME, DATABASE_ROLE FROM V$INSTANCE, V$DATABASE;—— 切换前，主库状态必须是OPEN，备库必须是MOUNTED，且STATUS是OPEN（不是STARTED） - Broker 会尝试自动启动新主库的监听器，如果
lsnrctl status显示监听未运行，或local_listener参数为空，切换过程会超时失败
Broker 初始化最麻烦的地方不在命令多，而在于它极度依赖底层 Oracle 参数和数据库状态的一致性。参数写错一个字母、归档没开、监听没起、甚至时间不同步（影响日志序列判断），都会让 dgmgrl 在某个环节静默失败。建议每步之后都用 SHOW CONFIGURATION 和 SHOW DATABASE 看实际状态，别只信自己的记忆。
