最大保护模式下主库宕机的直接原因是网络中断导致备库RFS无法响应，主库LGWR等待SYNC+AFFIRM确认超时后强制终止；关键参数组合为LGWR、SYNC、AFFIRM缺一不可，改NOAFFIRM则降级为最大可用性模式。
最大保护模式下主库宕机的直接原因
因为 MAXIMUM PROTECTION 模式强制要求事务在主库和至少一个备库上都完成写入（LGWR + SYNC + AFFIRM），网络中断导致备库 RFS 进程无法响应，主库 LGWR 就卡在等待确认的状态，超时后实例被强制终止。
关键参数组合决定了这个行为
主库的 LOG_ARCHIVE_DEST_2 配置中只要包含这三个关键词，就触发该机制：
-
LGWR：日志由 LGWR 进程直送，不等归档完成 -
SYNC：主库必须等待备库 RFS 写入 standby redo log 并返回成功 -
AFFIRM：RFS 必须将数据刷盘（fsync）后才回 ACK
三者缺一不可。哪怕只把 AFFIRM 换成 NOAFFIRM，主库就不会 abort，而是降级为最大可用性模式（MAXIMUM AVAILABILITY）继续运行。
常见误判点：监听停了 vs 网络断了
这两者对主库影响完全不同：
- 停备库监听（
lsnrctl stop）：主库仍能发日志，只是 RFS 接收失败；LGWR 会按REOPEN参数重试（如REOPEN=30），期间主库 DML 正常，不会宕机 - 断网络（
service network stop或防火墙拦截）：TCP 连接无法建立，LGWR 等不到任何响应，最终触发 Oracle 内部保护逻辑，报ORA-16098后强制 shutdown
查告警日志最准：TNS-00513: Destination host unreachable + Instance shutdown required to protect primary 是典型标志。
为什么不能靠调大超时来规避
Oracle 在 MAXIMUM PROTECTION 下不提供可配置的“等待超时”参数。它的设计哲学就是「宁可停机，也不冒丢失风险」。你改不了 LGWR 的等待行为，也改不了实例 abort 的触发条件——这是硬编码逻辑。
真正可控的只有两件事：确保网络链路稳定（专线、双物理路径）、或换用 MAXIMUM AVAILABILITY 模式。后者在网络中断时自动退化，但恢复后不会自动升回保护模式，需要人工干预确认。
