必须满足四个硬性条件：主备库均开启force_logging；备库处于mount状态、lgwr sync且noaffirm；备库配置standby redo log并mrp实时应用；切前停大事务，切后验证protection_level是否为maximum protection。
不能直接切，必须先满足四个硬性条件，否则 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION 一定失败。
主库和备库都必须开启 FORCE_LOGGING
很多人卡在 ORA-16627，查了半天参数，结果是备库没开强制日志——主库开了，备库不会自动继承。
- 检查命令：
SELECT FORCE_LOGGING FROM V$DATABASE;，主库和备库都必须返回YES - 主库执行：
ALTER DATABASE FORCE LOGGING; - 备库也得单独执行一次：
ALTER DATABASE FORCE LOGGING;（哪怕刚从主库复制过来） - 注意：首次开启会触发全量日志重写，DML 可能短暂变慢，避开业务高峰操作
备库必须是 MOUNT 状态 + SYNC 传输 + NOAFFIRM
最大保护模式只接受 LGWR SYNC 且备库处于 MOUNT，NOAFFIRM 是关键——用 AFFIRM 容易因存储延迟导致主库提交卡住。
- 确认备库状态：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;必须是PHYSICAL STANDBY和MOUNTED - 主库检查归档目标：
SELECT DEST_NAME, TRANSMISSION_MODE, AFFIRM FROM V$ARCHIVE_DEST_STATUS WHERE STATUS = 'VALID'; - 把目标备库的
LOG_ARCHIVE_DEST_2（或对应编号）设为：SERVICE=standby LGWR SYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=xxx - 如果用 Broker，先
DISABLE CONFIGURATION，Broker 不校验最大保护的底层约束
备库必须有 standby redo log 且 MRP 正在实时应用
ORA-16826 的本质是 Oracle 发现最近 5 秒内还有 redo 没同步完——哪怕只差几百字节，就会拒绝切换。
- 检查备库 standby redo log 是否存在：
SELECT * FROM V$STANDBY_LOG;返回至少一组非空记录（组数建议 ≥ 主库 online redo log 组数 + 1） - 确认实时应用状态：
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';，STATUS必须是APPLYING_LOG，且SEQUENCE#与主库V$LOG.HIGH_SEQUENCE#相差 ≤ 1 - 切之前停掉大事务（如批量导入），避免积压未传输 redo
- 命令执行后可能卡住 10–30 秒，这是后台做一致性握手，别 Ctrl+C 中断
切完立刻验证，别信“没报错就是成功”
执行完 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION 后，V$DATABASE.PROTECTION_MODE 显示 MAXIMUM PROTECTION 只是第一步，真正要盯的是 PROTECTION_LEVEL 字段是否同步变成 MAXIMUM PROTECTION——两者不一致说明内部校验没通过，实际仍是降级状态。
- 验证命令：
SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; - 如果
PROTECTION_LEVEL是RESYNCHRONIZATION或MAXIMUM PERFORMANCE，说明某处配置仍不满足，比如 standby redo log 大小不匹配、网络抖动导致瞬时不同步、或备库监听端口被防火墙拦截 - 此时主库其实已处于“半保护”状态：它会尝试 SYNC 写，但一旦失败就直接
shutdown abort，不是警告，是立即中止
