查主库LNS进程是否卡在NET_TIMEOUT重试：执行SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQ#, DELAY_MS FROM V$MANAGED_STANDBY WHERE PROCESS = 'LNS'；若STATUS为WRITING但DELAY_MS持续>1000，或频繁在CONNECTING/WAITING间跳变，即判定NET_TIMEOUT触发抖动，需将NET_TIMEOUT设为P99 RTT的2倍（如RTT=42ms则设200）、REOPEN设为NET_TIMEOUT/2（如100），并确认LGWR配置含ASYNC参数以避免退化为同步阻塞。
查主库LNS进程是否卡在NET_TIMEOUT重试
LGWR模式下，LNS进程负责把日志从online redo log推到备库。一旦网络抖动或备库响应慢，它就会反复等待、超时、重连——这个过程不报错，但会拖慢LGWR本身，引发log file sync飙升和提交延迟。
执行以下SQL确认LNS状态：
SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQ#, DELAY_MS FROM V$MANAGED_STANDBY WHERE PROCESS = 'LNS';
若STATUS是WRITING但DELAY_MS持续 > 1000（即超1秒），或频繁在CONNECTING/WAITING间跳变，基本可判定是NET_TIMEOUT触发了抖动。
-
NET_TIMEOUT默认180秒，在跨城/云环境极易误判——实测P99 RTT为42ms时，应设为200而非默认值 -
REOPEN必须 ≤NET_TIMEOUT，建议设为NET_TIMEOUT / 2（如REOPEN=100），否则故障恢复太慢 - 漏配
ASYNC参数（如只写LGWR不写ASYNC=256K）会导致LNS退化为同步阻塞行为
确认LGWR是否因AFFIRM未收到而挂起
最大保护或最高可用模式下，LGWR必须等备库返回AFFIRM才允许事务提交。如果备库SRL没就位、I/O慢、或MRP进程卡住，AFFIRM就迟迟不来，LGWR只能干等——这时log file sync平均等待会突增，且与log file parallel write无强相关。
先查备库SRL是否可用：
SELECT GROUP#, THREAD#, SEQUENCE#, STATUS FROM V$STANDBY_LOG;
必须有至少一组STATUS为ACTIVE或UNASSIGNED；空结果或全是UNUSED说明SRL未生效，AFFIRM实际被忽略。
- 主库
LOG_ARCHIVE_DEST_2中若含SYNC AFFIRM，但备库没SRL，Oracle不会报错，而是静默降级为异步 - 用
SELECT DEST_ID, AFFIRM, TRANSMIT_MODE FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;交叉验证：若AFFIRM = ENABLED但TRANSMIT_MODE = ASYNC，说明配置冲突，已被Oracle自动修正 - 备库
V$MANAGED_STANDBY中若PROCESS = 'MRP0'且STATUS长期为WAIT_FOR_GAP或APPLYING_LOG但SEQ#不更新，AFFIRM必然积压
区分LGWR抖动和备库MRP应用瓶颈
现象相似（apply lag涨、log file sync高），但根因相反：LGWR抖动是主库发不出去，MRP瓶颈是备库收得进但吃不下。错误归因会导致调参方向完全反向。
关键分界点看transport_lag和apply_lag的差值：
SELECT name, value FROM V$DATAGUARD_STATS WHERE name IN ('transport lag', 'apply lag');
若transport_lag > apply_lag + 30秒，问题在主库端传输链路（LNS、网络、SRL配置）；若两者接近且apply_lag单边上涨，则是备库MRP或I/O问题。
- 主库侧重点查
V$ARCHIVE_DEST_STATUS.error、tnsping丢包率、ping -s 1472的P99延迟 - 备库侧重点查
V$SYSTEM_EVENT中log file parallel write和db file sequential read平均等待是否超10ms -
STANDBY_MAX_DATA_DELAY=0只是控制延迟报告逻辑，设了≠实时，底层卡住照样延迟
ADG备库LGWR异常终止前的ORA-04021锁等待
在11.2.0.4+ ADG环境中，备库LGWR进程可能因parse lock争用主动终止实例，告警日志里紧跟着ORA-04021: timeout occurred while waiting to lock object。这不是普通DDL锁，而是内核层实例状态锁，前台硬解析会阻塞LGWR获取parse lock。
定位要点不是查V$LOCK，而是抓取宕机前1分钟的锁等待链：
SELECT blocking_session, blocking_session_status, event, sql_id FROM V$SESSION WHERE EVENT = 'enq: KO - fast object checkpoint' OR EVENT LIKE 'cursor:%';
若发现多个会话EVENT为cursor: pin S wait on X且blocking_session指向LGWR自身，就是典型ADG parse lock争用。
- 临时缓解：设
_adg_parselock_timeout=300（单位秒），避免LGWR过早放弃 - 根治方向：禁用
cursor_sharing=force，减少硬解析；或升级到12.2+，该Bug（16717701）已修复 - 注意：
ORA-04021对象名若显示为kjzduptcctx或为空，基本可排除用户表锁，直接按ADG内核锁处理
真实延迟永远藏在主备SCN差值里，而不是V$DATAGUARD_STATS的估算字段中；而LGWR抖动最隐蔽的信号，往往是log file sync等待时间波动剧烈，却查不到对应I/O或CPU瓶颈——这时候该回头再看一遍NET_TIMEOUT和REOPEN的数值是否贴合你的物理链路。
