在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 响应能力四者共同作用的结果，缺一不可。
