Oracle Data Guard中AFFIRM与NOAFFIRM区别详解

在MAXIMUM PERFORMANCE模式下，NOAFFIRM是唯一的合法选项。在此模式下，LGWR不会等待备库落盘便直接返回，这样虽能保障主库性能，但在极端情况下，可能会丢失几秒已提交的事务。而AFFIRM仅在SYNC传输且处于MAXIMUM A VAILABILITY或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 A VAILABILITY 或 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 响应能力四者共同作用的结果，缺一不可。