ORA-16516报错时，先确认Broker进程是否真在运行：查V$MANAGED_STANDBY无DMON/MRP0、dg_broker_start非TRUE或仅设MEMORY、未显式连接指定服务名（SERVICE_NAME= DB_UNIQUE_NAME）、监听未静态注册、配置文件路径不可写或损坏、drc.trc日志中藏有ORA-16571等根因。
ORA-16516 报错时，先确认 Broker 进程是否真在运行
ORA-16516 的字面意思是 “the current state does not allow the attempted operation”，但它几乎从不反映业务逻辑错误，而是 Broker（dmon）进程与数据库之间的通信断开或未就绪。最常见的情况是：你执行了 DGMGRL 命令，但 dmon 根本没起来，或者刚启动还没完成初始化。
验证方式不是看 ps -ef | grep dmon 是否有进程，而是直接在 SQL*Plus 里查：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
如果返回空或只有 ARCH/RFS 没有 MRP0 或 DMON，说明 Broker 没生效；或者查：
SHOW PARAMETER dg_broker_start;
结果必须是 TRUE 且 SCOPE 含 BOTH 或 SPFILE —— 如果只设了 MEMORY，重启后就失效，DGMGRL 就会静默报 ORA-16516。
连接 DGMGRL 时没指定正确上下文，也会触发 ORA-16516
很多人用 dgmgrl 回车后直接敲 connect /，以为连上了本地库，其实可能连的是默认实例（比如非 DG 环境的测试库），或者 OS 用户不是 oracle，导致认证失败但不报具体错，后续所有命令都返回 ORA-16516。
必须显式连接：
-
dgmgrl sys/<password>@<db_unique_name></db_unique_name></password>—— 注意这里<db_unique_name></db_unique_name>是你在tnsnames.ora中为该库定义的服务名，且其SERVICE_NAME必须等于该库的DB_UNIQUE_NAME - 主库和备库都要能被对方通过服务名解析并连接，不能只依赖
localhost或127.0.0.1 - 检查监听器是否静态注册：备库的
listener.ora中要有(GLOBAL_DBNAME = <db_unique_name>)</db_unique_name>条目，且lsnrctl status显示该服务状态为READY，不是UNKNOWN
Broker 配置文件损坏或路径不可写，导致状态无法加载
ORA-16516 经常伴随 ORA-16786: unable to access Data Guard broker configuration files 出现，但后者不一定打印出来。Broker 的配置文件（.dat）是二进制格式，不能手动编辑，一旦权限不对、磁盘满、文件系统只读或路径不存在，dmon 就无法加载状态，后续任何操作都会卡在“当前状态不允许”。
检查要点：
-
SHOW PARAMETER DG_BROKER_CONFIG_FILE1;返回路径是否存在？父目录是否已创建？Broker 不会自动建目录 - 文件属主必须是
oracle用户（不是root或grid），权限建议644；目录权限建议755 - 如果是 ASM 路径（如
+DATA/dgbroker/dr1prim.dat），确认 diskgroup 已挂载，且oracle用户有 ASM 权限 - 运行
df -h看对应文件系统是否空间耗尽，或mount | grep $(dirname $ORACLE_HOME)确认没被 remount 为只读
Broker 日志里藏着真正原因，别只盯着 ORA-16516
ORA-16516 是泛型错误，就像 HTTP 500，它本身不告诉你问题在哪。真正根因一定在 Broker 的独立日志里 —— $ORACLE_HOME/rdbms/log/drc<db_unique_name>.trc</db_unique_name> 和 drn<db_unique_name>.log</db_unique_name>。
例如，你看到 ORA-16516 后立刻去查 drcstandby.trc，可能发现一行：
ORA-16571: Data Guard configuration failed validation
接着往下翻，就会看到具体哪条校验失败：可能是主备库 LOG_ARCHIVE_CONFIG 参数不一致，也可能是某库的 DB_UNIQUE_NAME 在另一端的 tnsnames.ora 里没定义。
这种细节不会出现在 alert.log，也不会在 DGMGRL 交互界面显示 —— 忽略它，你就永远在循环 retry。
