主库hang住是因归档传输阻塞且log_archive_dest_2配置sync/mandatory，lgwr必须等待归档确认才能写下一个redo block；网络卡顿导致dml冻结。
主库HANG住不是因为“网络延迟高”，而是因为归档传输被阻塞，且LOG_ARCHIVE_DEST_2配置了SYNC或MANDATORY属性——此时LGWR必须等归档确认才敢写下一个redo block，网络一卡，整个DML就冻结。
确认是不是LGWR真被卡住，而不是假象
别急着改参数。先快速验证LGWR是否真的在等归档：
- 查
V$SESSION_WAIT：运行SELECT SID, EVENT, P1TEXT, P1, P2TEXT, P2 FROM V$SESSION_WAIT WHERE EVENT LIKE 'log file sync%' OR EVENT LIKE 'ARCH%';，若看到LGWR（PROGRAM含LGWR）在等log file sync且P1值长期不更新，基本坐实 - 看
V$ARCHIVE_DEST_STATUS：执行SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;，若STATUS是ERROR或DEFERRED，且ERROR含ORA-12170、ORA-12537或“timeout”，就是网络层失败的铁证 - 翻主库alert日志：搜
"ARCn: Archiving not possible"或"LGWR: Failed to archive log"，连续出现即说明归档链路已断
立刻止损：把SYNC/MANDATORY切到ASYNC/NOAFFIRM
这是最直接有效的止血操作。只要主库还能连上备库监听（tnsping通），就能切——不用重启，不丢数据：
- 执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db_stby LGWR ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db_stby' SCOPE=BOTH; - 强制归档切换一次：
ALTER SYSTEM ARCHIVE LOG CURRENT;，观察V$ARCHIVED_LOG中DEST_ID=2的新记录是否生成并标记STATUS=A - 注意：如果原配置含
MANDATORY，必须显式去掉，否则LGWR仍会等待；NOAFFIRM表示不等备库写盘确认，只等RFS进程接收成功即可
为什么不能只调大NET_TIMEOUT或REOPEN
这些参数治标不治本。当主库已HANG，LGWR根本不会走到超时逻辑——它卡在I/O提交前的同步等待点，连发包动作都没触发：
-
NET_TIMEOUT只对LGWR ASYNC模式下的网络重传生效；SYNC模式下该参数被忽略 -
REOPEN控制的是连接中断后的重试间隔，但LGWR卡住时连接往往还“活着”，只是没响应，REOPEN完全不触发 - 强行加大
NET_TIMEOUT到300秒，只会让HANG时间更长，业务停摆更久 - 真正要动的是传输模式本身：从SYNC→ASYNC，从WAIT→NOAFFIRM
后续必须补上的三件事
ASYNC只是应急，不是长期方案。网络问题不根治，迟早再爆：
- 用
ping -s 1472测主备间MTU路径（避开IP分片），查丢包率；用tnsping db_stby 10看平均延迟是否稳定在 - 检查备库端
RFS进程状态：SELECT PROCESS, STATUS, CLIENT_PID FROM V$MANAGED_STANDBY WHERE PROCESS='RFS';，若STATUS为CONNECTED但CLIENT_PID为空或反复变化，说明监听虽通，RFS无法稳定维持连接 - 确认主库
LOG_BUFFER≥100MB（尤其OLTP场景），太小会导致LGWR频繁刷buffer，放大网络抖动影响
ASYNC切换后主库立刻恢复，但备库可能已积压大量未传日志——这时别急着开ADG，先盯紧V$DATAGUARD_STATS里的transport lag，等它降到
