主库log file sync达78ms且log file parallel write仅1ms，表明瓶颈在Data Guard同步：LNS wait on SENDREQ和LGWR-LNS wait on channel高企，证实主库正等待备库ACK；核查LOG_ARCHIVE_DEST_2为SYNC+AFFIRM配置，需根据业务容忍度调整为ASYNC或NOAFFIRM。
主库提交变慢，awr里看到 log file sync 平均 78ms，基本可以断定是 data guard 传输拖慢的，不是磁盘或cpu问题。
查AWR中Top Events确认LNS是否成瓶颈
直接翻AWR报告的 “Top 5 Timed Foreground Events” 和 “Background Wait Events” 两节：
-
LNS wait on SENDREQ排名靠前 → 主库LNS进程在等备库回ACK，网络或备库I/O慢 -
LGWR-LNS wait on channel同时高 → LGWR被LNS卡住，无法及时完成本地日志写入 -
log file parallel write却只有 ~1ms → 本地redo写磁盘很快，排除存储问题
这组等待组合是典型的“DG SYNC+AFFIRM 配置下备库跟不上”的指纹。别急着调LGWR参数，先盯LNS和备库状态。
核对 LOG_ARCHIVE_DEST_2 的传输属性是否真需要SYNC+AFFIRM
执行：SELECT DEST_NAME, STATUS, PROTECTION_MODE, TRANSMIT_MODE, AFFIRM, DELAY FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;
-
TRANSMIT_MODE = 'SYNC'+AFFIRM = 'YES'→ 每次commit都等备库落盘，延迟必然高 - 若业务允许少量数据丢失（如报表库、测试环境），应改为：
LGWR ASYNC NOAFFIRM -
DELAY值非零（比如DELAY=30）只影响备库应用，不影响主库传输；但若误配了SYNC又加DELAY，会导致逻辑矛盾，部分版本会静默降级或报错
注意：NOAFFIRM 不等于不写备库——只是不等它写完就返回，LNS仍会异步推送，可靠性下降但性能提升明显。
检查备库是否真的在接收并写入redo
登录备库，确认以下三点是否全部满足：
- 备库处于
MOUNT或OPEN READ ONLY WITH APPLY状态（SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;） -
ARCHIVE_LAG_TARGET设得过大（如3600秒）会抑制实时传输，建议设为0或300以内 - 备库的
log_archive_dest_1路径是否有空间？V$ARCHIVE_DEST_STATUS中STATUS是否为VALID？ERROR列有没有报错？
常见陷阱：备库归档目标路径满了、归档目录权限不对、或者用了NFS但没开noac选项导致写入卡顿——这些都会让LNS在SENDREQ上死等。
用V$MANAGED_STANDBY看LNS实时行为
在主库查：SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQ#, BLOCK#, DELAY_MINS FROM V$MANAGED_STANDBY WHERE PROCESS = 'LNS';
-
STATUS = 'IDLE'→ LNS空闲，传输正常 -
STATUS = 'WAIT_FOR_LOG'→ LGWR还没给新日志，不是LNS问题 -
STATUS = 'WRITING'或长期卡在CONNECTED→ LNS正在发，但备库没回ACK，立刻去查备库网络连通性、监听是否响应、防火墙策略 -
BLOCK#长期不增长 → LNS根本没推进，大概率是备库连接中断或LOG_ARCHIVE_DEST_2配置失效
这个视图比AWR更实时，5秒刷一次，适合快速定位“此刻卡在哪”。AWR里的等待是历史汇总，容易掩盖瞬时抖动。
真正难啃的是跨地域、高延迟链路下的SYNC模式——哪怕网络RTT只有50ms，叠加备库I/O和确认回传，log file sync 也会轻松破百毫秒。这时候改配置不如改架构：要么切ASYNC，要么加备库本地SSD缓存redo，或者评估使用Far Sync实例分流LNS压力。
