EDIT DATABASE 命令需数据库处于 MOUNT 状态；LogXptMode 设为 SYNC 需底层归档目标启用 SYNC 属性；DelayMins 仅影响新接收日志；ORA-16664/16792 表示配置与实际不一致，须先修正底层参数再更新 Broker。
edit database 命令不生效？先确认数据库是否处于 MOUNT 状态
在 dgmgrl 中执行 edit database ... set property 失败，常见原因是目标库没在 mount 状态。data guard broker 要求主库或备库必须处于 mount（不能是 open），才能修改如 logxptmode、delaymins、binding 这类底层同步属性。
- 检查状态：
DGMGRL> SHOW DATABASE verbose 'db_name'，看Database Status是否为MOUNTED - 如果显示
OPEN，需先在数据库侧执行：ALTER DATABASE CLOSE;+STARTUP MOUNT; - 注意：
EDIT DATABASE修改的是 Broker 元数据，不是直接改初始化参数，所以ALTER SYSTEM无效，也无需重启实例
LogXptMode 改成 sync 却没走 SYNC？检查 redo transport 的实际路径和网络配置
LogXptMode 设为 SYNC 后仍出现异步行为，往往不是 Broker 配置问题，而是底层传输链路未满足强制同步条件。
- 必须确保主库
LOG_ARCHIVE_DEST_n对应的归档目标启用了SYNC属性（例如：LOG_ARCHIVE_DEST_2='SERVICE=standby SYNC AFFIRM ...'） - 检查
LOG_ARCHIVE_DEST_STATE_n是ENABLE，且VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - 网络层面：TCP Keepalive、防火墙超时、中间设备（如负载均衡器）可能中断长连接，导致 Broker 认为 SYNC 失败后自动降级为
ASYNC
修改 DelayMins 后延迟没变化？Broker 不会自动 apply delay 到已存在的归档日志
DelayMins 只控制新接收的归档日志是否延迟应用，不会 retroactively 延迟已传到备库但尚未应用的日志。
- 设为
30后，新传来的日志会等待 30 分钟再触发RECOVER MANAGED STANDBY DATABASE - 已到达但未应用的日志，仍会按当前恢复策略立即应用；要清空已有日志队列，可临时停恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再重新启动 - 注意：该值只对物理备库有效，快照备库（Snapshot Standby）不支持
DelayMins
Broker 报 ORA-16664 / ORA-16792？说明配置项冲突或不兼容
这两个错误常出现在修改 ProtectionMode 或 TransportLagThreshold 后，本质是 Broker 检测到当前配置与数据库实际能力不匹配。
-
ORA-16664：通常因主库未启用FORCE LOGGING，却尝试设为MAXIMUM AVAILABILITY或更高保护模式 -
ORA-16792：比如把LogXptMode设为SYNC，但对应LOG_ARCHIVE_DEST_n实际配的是ASYNC，Broker 拒绝写入不一致元数据 - 查冲突根源用：
SHOW DATABASE 'db_name' INCONSISTENT PROPERTIES - 修复顺序：先在 SQL*Plus 调整底层参数（如
ALTER DATABASE FORCE LOGGING），再回 DGMGRL 执行EDIT DATABASE
SHOW DATABASE verbose 输出里 Properties 和 Inconsistent Properties 两栏是否真正清空。 
