最大保护模式切换要求主库先停至MOUNT状态，备库需处于MOUNT或READ ONLY WITH APPLY状态；DGMGRL修改比SQL更安全，会执行完整前置校验，且改后须验证PROTECTION_MODE与TRANSMIT_MODE是否生效。
保护模式修改前必须停主库到MOUNT状态
最大保护（Maximum Protection）模式切换要求主库处于 MOUNT 状态，不是 OPEN。这点和另外两种模式不同——Maximum Availability 和 Maximum Performance 允许在线修改。一旦你执行 ALTER DATABASE SET PRIMARY DATABASE TO MAXIMUM PROTECTION 时主库是 OPEN 的，会直接报错：ORA-16625: cannot reach database "xxx" 或更直白的 ORA-16072: a minimum of one standby database destination is required，本质是校验失败而非网络问题。
实操建议：
- 先用
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;确认主库角色和状态 - 执行
SHUTDOWN IMMEDIATE→STARTUP MOUNT，再进行模式变更 - 备库此时必须处于
MOUNT或READ ONLY WITH APPLY状态，不能是完全关闭或只读未应用日志 - 修改完成后，主库需手动
ALTER DATABASE OPEN，Broker 不会自动帮你打开
DGMGRL里改模式比SQL命令更安全
用 DGMGRL 执行 EDIT DATABASE 'xxx' SET PROPERTY ProtectionMode = 'MaxProtection'; 会触发一整套前置检查：是否所有备库在线、日志传输是否正常、LOG_ARCHIVE_DEST_n 是否启用、DB_UNIQUE_NAME 是否匹配等。而裸 SQL 命令如 ALTER DATABASE SET DATABASE TO MAXIMUM PROTECTION 绕过这些校验，容易在后续 Switchover 时暴露问题，比如 ORA-16826: unable to apply redo。
常见错误现象：
-
DGMGRL返回ORA-16627: no standby databases support the protection mode：说明至少一个备库没配置STANDBY REDO LOG，或LOG_ARCHIVE_DEST_2的VALID_FOR写成了(ALL_LOGFILES, ALL_ROLES)而非(ONLINE_LOGFILES, PRIMARY_ROLE) - 执行成功但 Switchover 失败：大概率是备库的
DB_UNIQUE_NAME和主库LOG_ARCHIVE_CONFIG中声明的不一致，Broker 会静默忽略不匹配项 - 改完模式后主库自动 shutdown：这是
Maximum Protection的设计行为，说明它真检测到备库不可达，不是 Bug
三种模式对日志传输路径和参数的硬性依赖
模式切换不是改个名字就完事，它背后绑定着不同的日志传输行为和参数生效逻辑。例如：
-
Maximum Protection强制要求LGWR SYNC+STANDBY REDO LOG，如果LOG_ARCHIVE_DEST_2里写的是ASYNC或没建 standby redo，切换会卡在校验阶段 -
Maximum Availability允许LGWR ASYNC，但必须确保FAL_SERVER可达，否则主库降级为Maximum Performance后不会自动切回 -
Maximum Performance下ARCH进程传输归档日志，LOG_ARCHIVE_DEST_2的VALID_FOR必须包含(STANDBY_LOGFILES, STANDBY_ROLE)，否则备库收不到归档
验证方式：改完模式后立刻查 SELECT DEST_ID, STATUS, PROTECTION_MODE, TRANSMIT_MODE, AFFIRM FROM V$ARCHIVE_DEST_STATUS WHERE STATUS = 'VALID';，重点关注 PROTECTION_MODE 和 TRANSMIT_MODE 是否与预期一致。
Switchover 前必须重新验证保护模式生效状态
很多人改完模式就直接做 Switchover，结果在 PRE-SWITCHOVER CHECKS 阶段失败。因为 Broker 的配置元数据（dr*.dat）和数据库实际运行时的状态可能不同步。最典型的例子是：你在 DGMGRL 里设了 MaxAvailability，但主库的 V$DATABASE.PROTECTION_MODE 仍是 MAXIMUM PERFORMANCE，这说明控制文件没刷新。
解决办法只有两个：
- 在主库上执行一次
ALTER SYSTEM SWITCH LOGFILE;，强制触发一次日志切换和 Broker 状态同步 - 或者重启 DMON 进程：
SRVCTL STOP CONFIG -D <db_name></db_name>→SRVCTL START CONFIG -D <db_name></db_name>（RAC 环境下） - 然后务必运行
DGMGRL> SHOW DATABASE VERBOSExxx和SELECT PROTECTION_MODE FROM V$DATABASE;双重确认
真正容易被忽略的是：保护模式修改后，LOG_ARCHIVE_DEST_STATE_2 的值会被 Broker 自动设为 DEFER（尤其从 MaxPerformance 切过来时），必须手动 ENABLE，否则日志根本传不出去。
