Broker中修改ProtectionMode不生效，根本原因是数据库实例未同步配置，需同步调整LogXptMode、DelayMins等关联参数，并执行日志切换、验证DEST_ROLE和VALID_FOR等细节。
Broker里改ProtectionMode不生效？先看数据库实际状态
broker中执行edit database set property protectionmode后，模式没变，不是命令写错了，而是底层数据库实例没同步到新配置。broker只是协调层，真正起作用的是每个数据库的log_archive_dest_n配置和standby_file_management等参数是否匹配目标模式要求。
常见错误现象：DGMGRL> SHOW DATABASE VERBOSITY显示Protection Mode: MaxPerformance，但SELECT PROTECTION_MODE FROM V$DATABASE仍是MAXIMUM PERFORMANCE——这说明Broker元数据已更新，但数据库未重读配置。
- 必须在主库上执行
ALTER SYSTEM ARCHIVE LOG CURRENT触发一次日志切换，让Standby识别新属性 - 检查Standby是否处于
MANAGED RECOVERY状态：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY，如果MRP0是WAIT_FOR_LOG或NOT APPLYING，模式不会生效 -
ProtectionMode设为MAXIMUM AVAILABILITY时，主库LOG_ARCHIVE_DEST_2的SYNC和AFFIRM必须同时启用，缺一不可
EDIT DATABASE SET PROPERTY的三个关键参数组合
Broker中调整保护模式，本质是批量设置一组依赖属性。只改ProtectionMode字段，大概率失败；必须同步校准关联项。
-
LogXptMode：决定日志传输方式。ASYNC对应MAXIMUM PERFORMANCE，SYNC对应MAXIMUM AVAILABILITY，Broker不会自动帮你切 -
DelayMins：设为非零值时，即使ProtectionMode是MAXIMUM AVAILABILITY，实际也退化为MAXIMUM PERFORMANCE（因为延迟意味着异步） -
ReopenSecs和NetTimeout：影响故障切换响应速度，在MAXIMUM AVAILABILITY下建议设为30和30，否则网络抖动可能触发误切
示例：把standby设为最大可用，需一次性执行：
EDIT DATABASE 'stby_db' SET PROPERTY LogXptMode='SYNC'; EDIT DATABASE 'stby_db' SET PROPERTY ProtectionMode='MAXIMUM AVAILABILITY'; EDIT DATABASE 'stby_db' SET PROPERTY DelayMins='0';
为什么SHOW CONFIGURATION显示Success但模式仍不对
Broker的SHOW CONFIGURATION只验证语法和连接性，不校验数据库内部参数一致性。最常被忽略的是DB_UNIQUE_NAME大小写敏感导致的配置错位——Broker里写的'STBY'，但数据库实际是'stby'，属性就根本没应用过去。
- 用
SHOW DATABASE 'xxx'确认Broker中记录的DB_UNIQUE_NAME和V$DATABASE.DB_UNIQUE_NAME完全一致（含大小写） - 检查
V$DATAGUARD_CONFIG中所有数据库的DEST_ROLE是否正确，比如误把物理备库配成PHYSICAL STANDBY却启用了FAR SYNC角色 - Oracle 12.1+中，若使用
FASTSTART FAILOVER，ProtectionMode必须为MAXIMUM AVAILABILITY，否则ENABLE FAST_START FAILOVER会静默失败
Broker配置生效后的验证盲区
很多人以为SHOW DATABASE里Protection Mode字段变了就完事了，其实最关键的验证点在日志归档路径和实际传输行为上。
- 查主库
V$ARCHIVE_DEST_STATUS中对应Standby的STATUS是否为VALID，TRANSMISSION_MODE是否匹配设定（如SYNC） - 查Standby的
V$ARCHIVED_LOG，对比APPLIED列是否为YES且REGISTRAR包含RFS——如果只有ARCH，说明日志压根没传过来 - 用
SELECT * FROM V$DATAGUARD_STATS看apply lag和transport lag，两者都接近0才代表MAXIMUM AVAILABILITY真正跑起来了
最麻烦的情况是：Broker显示一切正常，但主库日志归档目录里没有发往Standby的日志文件，此时一定是LOG_ARCHIVE_DEST_n的VALID_FOR属性没覆盖(ONLINE_LOGFILES,PRIMARY_ROLE)，这个细节90%的人会漏查。
