NOAFFIRM是MAXIMUM PERFORMANCE模式下唯一合法选择，LGWR不等待备库落盘即返回，保障主库性能但极端情况下可能丢失几秒已提交事务；AFFIRM仅在SYNC传输且MAXIMUM AVAILABILITY/PROTECTION模式下生效，强制等待备库落盘确认。
AFFIRM 和 NOAFFIRM 的核心区别在于：LGWR 是否等待备库完成磁盘写入（即 standby redo log 落盘）才返回成功。 这不是可选的“优化开关”，而是直接决定主库事务提交行为与数据安全边界的硬约束。配错会直接导致“看着像同步，实则异步丢数据”——尤其在 MAXIMUM PERFORMANCE 模式下误用 AFFIRM 时，Oracle 甚至不报错，只静默忽略。
NOAFFIRM 是 MAXIMUM PERFORMANCE 模式下唯一合法且安全的选择
在 PROTECTION_MODE = MAXIMUM PERFORMANCE 下，LOG_ARCHIVE_DEST_n 中必须显式指定 NOAFFIRM，且传输模式必须为 ASYNC。否则：
-
AFFIRM会被 Oracle 静默忽略，配置看似存在，实际行为等同于NOAFFIRM - 若误配
AFFIRM+ASYNC，V$ARCHIVE_DEST_STATUS 可能仍显示AFFIRM = YES，但TRANSMIT_MODE是ASYNC→ 此时AFFIRM完全无效 - 主库性能不受影响，但极端场景（主库崩溃 + 网络中断 + online redo 未刷盘）下，最后几秒已提交事务可能丢失
-
NET_TIMEOUT（默认 30 秒）控制 LNS 单次重试等待上限，缩短它仅加快故障感知，不改变 NOAFFIRM 的语义
AFFIRM 只在 SYNC 传输下才真正起作用
AFFIRM 不是独立生效的参数，它必须和 SYNC 绑定使用，且仅在 MAXIMUM AVAILABILITY 或 MAXIMUM PROTECTION 模式下被设计为合法组合。常见误判点：
- 查
V$ARCHIVE_DEST_STATUS时，仅看AFFIRM = YES不够，必须同时满足：TRANSMIT_MODE = SYNC、STATUS = VALID、PROTECTION_MODE匹配 - RAC 环境中，每个实例需单独查询
V$ARCHIVE_DEST_STATUS，实例间配置可能不一致 - 主库 LGWR trace 文件中出现
NSS.*sync或waiting for standby ack才说明真正在等；否则就是“伪 AFFIRM” - 备库磁盘响应慢（如 NFS 延迟高），可能导致 AFFIRM 等待超时后 LGWR 强制返回，此时事务已提交，但日志未落盘
如何验证当前配置是否真正在用 AFFIRM 或 NOAFFIRM
不能只看 LOG_ARCHIVE_DEST_n 参数字符串，必须查运行时状态：
- 执行：
SELECT DEST_NAME, TRANSMIT_MODE, AFFIRM, STATUS, PROTECTION_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; - 对
NOAFFIRM场景：确认TRANSMIT_MODE = ASYNC且AFFIRM = NO（不是 NULL 或 YES） - 对
AFFIRM场景：确认TRANSMIT_MODE = SYNC且AFFIRM = YES且STATUS = VALID - 若
STATUS为ERROR或INACTIVE，说明归档路径未启用，再正确的 AFFIRM/NOAFFIRM 也无意义
最容易被忽略的是：AFFIRM 在 SYNC 下也不是绝对可靠的“零丢失”保障——它只保证日志已写入备库 standby redo log，不保证后续应用（MRP）是否及时、是否出错。真正的数据保护边界，取决于保护模式 + 传输模式 + AFFIRM/NOAFFIRM + 备库 I/O 响应能力四者共同作用的结果，缺一不可。
