MAXIMUM PROTECTION模式下仅当配置SYNC AFFIRM、备库启用STANDBY REDO LOG且为PHYSICAL STANDBY并开启REAL-TIME APPLY时，才能实现真正零数据丢失。
Max Protection 模式下必须用 SYNC AFFIRM 才算真正零丢失
oracle data guard 的 maximum protection 模式本身不保证零数据丢失，关键取决于 redo 传输的同步级别。只有配置为 sync affirm，才能确保主库提交事务前，redo 日志不仅被网络传到备库，还被写入备库的磁盘（log_archive_dest_n 的 affirm 属性生效）。若误配成 sync noaffirm，备库仅写入内存缓冲区就返回确认——主机断电或实例崩溃时，这部分 redo 就丢了。
-
LOG_ARCHIVE_DEST_2必须显式指定SYNC AFFIRM，不能只写SYNC - 备库必须启用
STANDBY REDO LOG，且大小、组数 ≥ 主库 online redo log，否则AFFIRM会失败并降级为NOAFFIRM - 主库
COMMIT会阻塞，直到收到备库磁盘写入完成的 ACK，网络延迟 > 5ms 或存储响应慢会导致明显性能抖动
备库必须是 PHYSICAL STANDBY，且开启实时应用（REAL-TIME APPLY）
Logical standby 不支持 MAXIMUM PROTECTION，因为其 SQL Apply 是异步解析和执行，无法满足同步写磁盘的原子性要求。Physical standby 才能通过 Redo Apply 原始块变更，配合 SYNC AFFIRM 实现物理层一致性。
- 建库时必须用
DATABASE GUARD ALL（默认），禁用STANDBY DATABASE GUARD NONE，否则 DML 可能意外在备库执行，破坏角色一致性 - 启动实时应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT—— 缺少USING CURRENT LOGFILE就只是归档日志应用，延迟不可控 - 检查是否真正在实时应用：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS', 'MRP0')；MRP0的STATUS应为APPLYING_LOG，且SEQUENCE#与主库V$LOG_HISTORY最新序号差 ≤ 1
主备之间网络和存储必须满足“双写确认”硬性条件
SYNC AFFIRM 不是 Oracle 单方面能控制的——它依赖底层链路的确定性。任何一环超时或丢包，都会触发 ORA-16198（timeout received from network）、ORA-16057（DG not receiving heartbeats），最终导致主库挂起（LGWR 进程等待）甚至自动降级为 MAXIMUM AVAILABILITY。
- 主备间建议使用专用万兆光纤直连，避免共享交换机或跨网段路由；TCP keepalive 时间需调小（如
net.ipv4.tcp_keepalive_time=30），防止连接假死 - 备库存储必须是本地 SAS/NVMe 或低延迟 SAN，LUN 需关闭写缓存（
WRITE_THROUGH模式），否则AFFIRM返回的“已落盘”实际还在阵列缓存中 - 主库
LOG_ARCHIVE_DEST_STATE_2必须为ENABLE，且V$DATAGUARD_CONFIG中PROTECTION_MODE显示MAXIMUM PROTECTION—— 若显示RESOLVING或MAXIMUM AVAILABILITY，说明配置未真正生效
切换后原主库无法自动恢复，必须手动重建或闪回
在 MAXIMUM PROTECTION 下发生故障切换（switchover/failover）后，原主库因最后几条 redo 未被备库确认而处于“分裂”状态，STARTUP MOUNT 后直接 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会报 ORA-1666（standby database out of sync）。它不是简单启个进程就能跟上。
- 最稳妥方式：用
FLASHBACK DATABASE回退到切换前的 SCN（需提前开启闪回区并设置足够DB_FLASHBACK_RETENTION_TARGET） - 若无闪回，只能重新搭建物理备库——用 RMAN 备份 +
DUPLICATE TARGET DATABASE FOR STANDBY，耗时长且需停业务窗口 - 切勿尝试用
ALTER DATABASE ACTIVATE STANDBY DATABASE强制激活原主库，这会彻底破坏 Data Guard 配置，且可能产生不可逆的数据块损坏
真正实现零丢失，靠的不是模式开关，而是从网络路径、存储行为、Oracle 参数到运维流程的全链路对齐。任何一个环节松动，MAXIMUM PROTECTION 就只是名字而已。
