ORA-16792表示DG Broker元数据与数据库实际参数值不一致，并非故障，但会阻塞ENABLE CONFIGURATION；须用show database verbose定位InconsistentProperties等具体项，再通过检查dmon进程、监听注册及同步spfile参数（如ALTER SYSTEM SET ... SCOPE=BOTH）修复。
ora-16792 不是数据库故障，而是 dg broker 元数据和数据库实际参数值对不上——它不拦你切换，但会卡住 enable configuration，且拒绝自动修复。
用 show database verbose 定位具体哪几项不一致
执行 show configuration 只能看到 “Warning: ORA-16792”，根本不知道错在哪。必须对每个库单独运行：show database verbose <db_name>
重点关注三类字段：
-
InconsistentProperties：比如显示'(monitor)'，说明 Broker 想读这个属性，但数据库没返回（常见于未启 observer 或 observer 失联） -
InconsistentLogXptProps：典型如LogXptMode、NetTimeout、ArchiveLagTarget等，Broker 元数据存的是你之前edit database set的值，而数据库 spfile 里压根没设，Oracle 就按默认值跑 - 带
(monitor)标记的LogXptStatus、RecvQEntries：Broker 连不上数据库的dmon进程，不是传输断了，是 Broker 自己失联了
确认 dmon 进程存活且监听注册正确
Broker 连不上数据库，90% 是因为 dmon 进程挂了或监听没配 _DGMGRL 服务。先查进程：ps -ef | grep dmon
再验证监听是否能通：tnsping <StaticConnectIdentifier>（该值来自 show database verbose 输出）
- 如果
tnsping失败，去检查listener.ora，确保有GLOBAL_DBNAME = <db_unique_name>_DGMGRL条目，且SID_NAME和ORACLE_HOME正确 - 别用
_DGB或自定义后缀，Oracle 官方只认_DGMGRL；顺序上GLOBAL_DBNAME必须在SID_NAME前面，否则某些版本会忽略 - 数据库不能是
RESTRICTED模式，MOUNT或OPEN才行
让 Broker 读到真实值：优先同步 spfile 参数
ORA-16792 的根源是 Broker 记的值 ≠ 数据库当前生效值。Broker 不会覆盖你手动改的参数，所以得先让数据库“承认”那个值——写进 spfile：
- 查当前值：
show parameter ArchiveLagTarget（举例），若输出为0，但 Broker 元数据存的是空或30，就得统一 - 执行：
ALTER SYSTEM SET ArchiveLagTarget=0 SCOPE=BOTH SID='*';（注意加SID='*'，RAC 环境必须） - 同理处理
LogArchiveMinSucceedDest、LogArchiveFormat、DataGuardSyncLatency等所有标红的项 - 改完不用重启，但要等 Broker 下次轮询（通常 30 秒内）。可手动触发：
enable configuration，失败就再试一次
别用 edit database set 强行覆盖
有人想省事，直接在 DGMGRL 里执行：edit database 'std' set property ArchiveLagTarget='0';
这只会让不一致更顽固——Broker 元数据改了，数据库 spfile 还是旧的，默认值和 Broker 值继续打架。
- Broker 设计就是“只读校验，不自动写回”，硬覆盖等于绕过一致性检查
- 真正生效的永远是 spfile + 实例重启（或
SCOPE=BOTH动态生效） - 如果某参数在 spfile 中是空的（
ISDEFAULT=TRUE），Broker 却存了非空值，那它一定报 ORA-16792；唯一解法是显式设一遍
最常被忽略的一点：LogArchiveFormat 在 12c+ 默认启用 DB_UNIQUE_NAME 和 PLUGGABLE_DATABASE 扩展，但 Broker 元数据可能还存着老格式（如 %t_%s_%r.dbf）。此时必须用 ALTER SYSTEM SET LogArchiveFormat=... 显式写死，否则每次重启都可能触发新不一致。
