maximum protection模式下必须显式配置sync affirm，否则会降级为maximum availability；standby redo log大小和组数须满足硬性要求；仅physical standby支持该模式；需启用real-time apply；validate database archivelog all是检验归档链scn连续性的终极手段。
MAXIMUM PROTECTION模式下必须显式配置SYNC AFFIRM
选了MAXIMUM PROTECTION不等于自动零丢失。Oracle只检查模式设置，不校验底层传输参数是否匹配。关键看log_archive_dest_2里有没有SYNC AFFIRM——缺这个，模式会悄悄降级为MAXIMUM AVAILABILITY，主库提交时只等备库内存接收就返回，断电即丢。
验证命令：SELECT DEST_NAME, STATUS, TRANSMIT_MODE, AFFIRM FROM V$ARCHIVE_DEST WHERE DEST_ID = 2；AFFIRM列必须是YES，TRANSMIT_MODE必须是SYNC。如果看到AFFIRM = NO或TRANSMIT_MODE = ASYNC，立刻修正配置：ALTER SYSTEM SET log_archive_dest_2='SERVICE=stdby SYNC AFFIRM ...' SCOPE=BOTH。
STANDBY REDO LOG必须满足大小和组数硬性要求
AFFIRM生效的前提是备库能真正把redo写进磁盘文件。如果STANDBY REDO LOG缺失、太小或组数不够，LGWR在主库提交时会卡住，报ORA-16072或直接降级传输模式。
- 每组
STANDBY REDO LOG大小 ≥ 主库对应ONLINE REDO LOG单组大小（例如主库是2G，备库不能用512M） - 组数 ≥ 主库
ONLINE REDO LOG组数（主库4组，备库至少4组） - 创建后查
SELECT GROUP#, THREAD#, SEQUENCE#, BYTES, STATUS FROM V$STANDBY_LOG，状态不能是UNASSIGNED
必须是PHYSICAL STANDBY + REAL-TIME APPLY
LOGICAL STANDBY根本不支持MAXIMUM PROTECTION，它走SQL Apply路径，解析、转换、执行全异步，无法保证物理块级同步写盘原子性。只有PHYSICAL STANDBY才能配合SYNC AFFIRM实现真正零丢失。
实时应用命令必须带USING CURRENT LOGFILE：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT。漏掉这个参数，MRP进程只会拉归档日志，延迟从秒级变成分钟甚至小时级。
验证是否真在实时应用：SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'；STATUS应为APPLYING_LOG，且SEQUENCE#与主库V$LOG_HISTORY最新序号差 ≤ 1。
VALIDATE DATABASE才是归档链SCN连续性的终极校验手段
ARCHIVE LOG LIST和V$ARCHIVED_LOG都不可靠——它们只反映控制文件里“注册过”的日志，对传输失败后被自动删除、或根本没来得及归档的redo完全无感。真正缺口藏在SCN间隙里。
在备库MOUNT状态下运行：VALIDATE DATABASE ARCHIVELOG ALL。输出中只要出现Archive Log SCN Gap或Missing Archive Log，就说明存在不可恢复的数据断点。比如gap from 1000 to 1099，代表这100个SCN区间内至少缺一个归档，且无法通过现有链推导补全。
注意：该命令不校验文件内容是否损坏，只确认控制文件元数据与物理文件是否存在、SCN能否衔接；若备库配了DELAY属性，需先确认延迟日志已超时，否则会被误判为缺失。
网络和存储链路的确定性才是SYNC AFFIRM落地的最后防线。主库LGWR → 网络 → 备库RFS → 写入STANDBY REDO LOG磁盘 → 返回ACK，任何一环超时或抖动，都会导致主库挂起或降级。这点没法靠数据库参数兜底，得靠基础设施层压测验证。
