最大保护模式要求主备库同步写入且强确认，未配全STANDBY REDO LOG、SYNC AFFIRM参数、FORCE LOGGING等前提时，ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION会报错或静默失败；切换后若备库异常，主库将主动shutdown以保数据零丢失。
最大保护模式不能直接在已有Data Guard配置上“切过去”——它要求同步传输、强制写入备库standby redo log，且主库必须能实时确认，否则会自动shutdown。没配好LOG_ARCHIVE_DEST_n参数、没开STANDBY REDO LOG、没启FORCE LOGGING，执行ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION会报错或静默失败。
确认前提条件是否全部满足
最大保护模式不是“设个参数就生效”，它是一整套强依赖链：
- 主库和备库都必须处于
ARCHIVELOG模式，且主库已启用FORCE LOGGING（ALTER DATABASE FORCE LOGGING） - 备库必须有至少一组
STANDBY REDO LOG，大小、组数要 ≥ 主库ONLINE REDO LOG；只靠ARCHIVE LOG无法支撑SYNC传输 -
LOG_ARCHIVE_DEST_2（或你用于DG的dest）必须显式指定SYNC AFFIRM，例如：LOG_ARCHIVE_DEST_2='SERVICE=stby_db LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby_db' - 主备库
DB_UNIQUE_NAME不能相同，且tnsnames.ora中service名必须能双向连通（主→备、备→主）
为什么ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION会卡住或报ORA-16627
这条命令不是单纯改个字段，它会实时验证整个保护链是否就绪。常见失败原因：
- 备库
STANDBY REDO LOG缺失或状态为UNASSIGNED（查V$STANDBY_LOG） -
LOG_ARCHIVE_DEST_2的VALID_FOR没包含PRIMARY_ROLE，导致主库不认为该dest可用于保护模式切换 - 备库MRP进程未启动（
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT没执行） - 网络延迟高或LNS进程异常，主库发不出redo或收不到AFFIRM确认，超时后拒绝切换
执行前务必先跑：SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2，确保STATUS是VALID且ERROR为空。
SYNC和AFFIRM必须同时存在，缺一不可
很多配置只写SYNC，以为就够了，但最大保护要求“写入磁盘并确认”。区别如下：
-
SYNC NOAFFIRM：主库等网络发送完成即提交，不等备库落盘——这属于最高可用模式的底线，不满足最大保护 -
SYNC AFFIRM：主库必须收到RFS进程将redo写入STANDBY REDO LOG磁盘的确认才提交——这是最大保护的硬性门槛 - 如果备库没开
STANDBY REDO LOG，即使配了AFFIRM，RFS也只能写归档目录，无法返回有效确认，主库最终会hang住或报ORA-16198
切换后主库意外shutdown？先看ALERT.LOG里有没有LGWR: terminating instance due to error 16038
这是最大保护模式最典型的自保行为：一旦检测到所有SERVICE目标不可达（比如备库宕机、网络中断、standby redo满），主库会主动终止实例。这不是bug，是设计如此。
- 恢复流程不是重启主库就行，必须先修复备库（启动MRP、清空阻塞的standby redo）、确认
V$ARCHIVE_DEST状态正常，再用STARTUP拉起主库 - 日常运维中，建议在备库侧部署监控：
SELECT PROCESS, STATUS, CLIENT_PROCESS FROM V$MANAGED_STANDBY，重点盯LNS（主库）和RFS（备库）是否ACTIVE - 别指望Broker（DGMGRL）能绕过这个限制——
EDIT DATABASE 'prim' SET PROPERTY 'LogXptMode'='SYNC'只是改配置，真正生效仍需底层传输链就绪
最大保护模式的复杂点不在命令本身，而在于它把主库的命运和备库的IO稳定性、网络可靠性、日志路径权限全部绑死。任何一个环节掉链子，主库就停摆——这点必须在上线前用断网、kill rfs、填满standby redo等方式实测验证。
