Oracle Data Guard AFFIRM与NOAFFIRM有何区别

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。否则：

1. AFFIRM 会被 Oracle 静默忽略，配置看似存在，实际行为等同于 NOAFFIRM
2. 若误配 AFFIRM + ASYNC，V$ARCHIVE_DEST_STATUS 可能仍显示 AFFIRM = YES，但 TRANSMIT_MODE 是 ASYNC → 此时 AFFIRM 完全无效
3. 主库性能不受影响，但极端场景（主库崩溃 + 网络中断 + online redo 未刷盘）下，最后几秒已提交事务可能丢失
4. NET_TIMEOUT（默认 30 秒）控制 LNS 单次重试等待上限，缩短它仅加快故障感知，不改变 NOAFFIRM 的语义

AFFIRM 只在 SYNC 传输下才真正起作用

AFFIRM 不是独立生效的参数，它必须和 SYNC 绑定使用，且仅在 MAXIMUM AVAILABILITY 或 MAXIMUM PROTECTION 模式下被设计为合法组合。常见误判点：

1. 查 V$ARCHIVE_DEST_STATUS 时，仅看 AFFIRM = YES 不够，必须同时满足：TRANSMIT_MODE = SYNC、STATUS = VALID、PROTECTION_MODE 匹配
2. RAC 环境中，每个实例需单独查询 V$ARCHIVE_DEST_STATUS，实例间配置可能不一致
3. 主库 LGWR trace 文件中出现 NSS.*sync 或 waiting for standby ack 才说明真正在等；否则就是“伪 AFFIRM”
4. 备库磁盘响应慢（如 NFS 延迟高），可能导致 AFFIRM 等待超时后 LGWR 强制返回，此时事务已提交，但日志未落盘

如何验证当前配置是否真正在用 AFFIRM 或 NOAFFIRM

不能只看 LOG_ARCHIVE_DEST_n 参数字符串，必须查运行时状态：

1. 执行：SELECT DEST_NAME, TRANSMIT_MODE, AFFIRM, STATUS, PROTECTION_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
2. 对 NOAFFIRM 场景：确认 TRANSMIT_MODE = ASYNC 且 AFFIRM = NO（不是 NULL 或 YES）
3. 对 AFFIRM 场景：确认 TRANSMIT_MODE = SYNC 且 AFFIRM = YES 且 STATUS = VALID
4. 若 STATUS 为 ERROR 或 INACTIVE，说明归档路径未启用，再正确的 AFFIRM/NOAFFIRM 也无意义

最容易被忽略的是：AFFIRM 在 SYNC 下也不是绝对可靠的“零丢失”保障——它只保证日志已写入备库 standby redo log，不保证后续应用（MRP）是否及时、是否出错。真正的数据保护边界，取决于保护模式 + 传输模式 + AFFIRM/NOAFFIRM + 备库 I/O 响应能力四者共同作用的结果，缺一不可。