NOAFFIRM是Max Performance模式下唯一安全的传输模式；LGWR不等待备库确认，保障主库性能，但极端情况下可能丢失几秒内已提交事务，且ASYNC+AFFIRM组合已被弃用。
NOAFFIRM 是 Max Performance 模式下唯一安全的传输模式
oracle data guard 的 log_archive_dest_n 中设为 async 时，affirm 和 noaffirm 决定了 lgwr 是否等待网络 i/o 完成。在 maximum performance 模式下，必须用 noaffirm；否则主库会因等待备库确认而卡住写入，实际退化为类似 maximum availability 的行为。
常见错误现象：ARCH 进程持续挂起、log file sync 等待飙升、主库事务明显变慢——十有八九是误配了 AFFIRM 却又没配好备库网络或磁盘响应。
-
NOAFFIRM：LGWR 不等备库写入完成就返回，主库性能无额外负担，但极端情况下（如网络断开瞬间主库崩溃）可能丢失已提交事务 -
AFFIRM：强制 LGWR 等待备库落盘确认，本质是同步语义，与MAXIMUM PERFORMANCE的设计目标冲突 - 即使备库启用了
STANDBY_FILE_MANAGEMENT=AUTO或DB_FILE_NAME_CONVERT，也不改变该约束
如何验证当前配置是否真正在用 NOAFFIRM + ASYNC
不能只看 LOG_ARCHIVE_DEST_n 参数值，要查运行时实际生效的属性。尤其注意 RAC 环境中不同实例可能配置不一致。
执行以下查询确认：
SELECT DEST_NAME, STATUS, PROTECTION_MODE, TRANSMIT_MODE, AFFIRM, VALID_ROLE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
-
TRANSMIT_MODE必须为ASYNC，不是SYNC或空 -
AFFIRM字段必须显示NO（不是YES，也不是NULL） -
STATUS应为VALID，若为ERROR或INACTIVE，说明归档路径未真正启用 - RAC 下需对每个实例单独查
V$ARCHIVE_DEST_STATUS，别只查 INSTANCE 1
NOAFFIRM 下主库崩溃时可能丢数据，但不是“随便丢”
很多人以为 NOAFFIRM 就等于“裸奔”，其实 Oracle 仍有缓冲层保护：LGWR 把日志发给 LNS 进程后即返回，LNS 在后台异步重试发送，且默认启用 NET_TIMEOUT 控制单次等待上限（默认 30 秒）。
- 真正可能丢失的是“刚发出、尚未被 LNS 成功投递”的那部分 redo，通常仅几 MB，对应几秒内事务
- 如果网络中断但主库仍在运行，LNS 会持续重试，不会丢；只有主库崩溃+网络未恢复+本地 online redo 还没刷盘，才触发丢失
- 可通过
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stby ASYNC NOAFFIRM NET_TIMEOUT=10' SCOPE=BOTH;缩短超时，加快故障感知，但不会提升安全性
Max Performance 模式下 AFFIRM 的唯一合法用途是 SYNC 传输
如果你看到文档或脚本里把 AFFIRM 和 ASYNC 同时写进一个 LOG_ARCHIVE_DEST_n，基本可以判定配置错误或理解偏差。Oracle 官方明确：ASYNC + AFFIRM 组合在 11gR2 及以后版本已被标记为“deprecated”，19c 中虽仍接受语法，但实际忽略 AFFIRM，等效于 NOAFFIRM。
- 想用
AFFIRM？只能配SYNC，并切换到MAXIMUM AVAILABILITY或MAXIMUM PROTECTION -
MAXIMUM PERFORMANCE模式本身不允许AFFIRM生效，参数校验逻辑在ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE时就已隐含约束 - 检查
V$DATABASE.PROTECTION_LEVEL和V$DATABASE.PROTECTION_MODE，二者必须都是MAXIMUM PERFORMANCE，否则配置未真正激活
最常被忽略的一点：DG Broker 配置和手动 SQL 配置可能不一致。Broker 会覆盖部分手动设置，务必用 DGMGRL 的 SHOW DATABASE VERBOSITY 对照验证，而不是只信 SHOW PARAMETER。
