主库查LNS实时状态应直接查询V$MANAGED_STANDBY，STATUS为'WAIT_FOR_SEND'或'SENDING'且DELAY_MINS>0表明传输链路卡顿，STATUS='IDLE'但SEQ#不涨则说明归档未触发，需检查V$ARCHIVE_DEST_STATUS.ERROR列。
主库查LNS实时状态，别只看进程是否存在
备库上查不到 lns 进程完全正常——它只在主库运行。所谓“lns慢”，本质是主库 lns 等待备库 ack 或写入卡住。直接查主库：v$managed_standby 才是第一手证据。
SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQ#, BLOCK#, DELAY_MINS FROM V$MANAGED_STANDBY WHERE PROCESS = 'LNS';-
STATUS = 'WAIT_FOR_SEND' or 'SENDING' 且 DELAY_MINS > 0→ 真卡在传输链路 -
STATUS = 'IDLE'但SEQ#不涨 → 主库根本没触发归档发送，先查V$ARCHIVE_DEST_STATUS的ERROR列 - 别信
ps -ef | grep lns，它只告诉你进程在不在，不告诉你它在等什么
AWR里抓LNS等待事件，确认是不是真瓶颈
Log file sync 高 ≠ LNS问题，必须交叉验证 AWR 报告里的等待事件组合。重点盯两处：
- “Top 5 Timed Foreground Events”：如果
log file sync平均 > 20ms，但log file parallel write - “Background Wait Events”：出现高频
LNS wait on SENDREQ或LGWR-LNS wait on channel→ 明确指向备库响应慢或网络延迟 - 若
LNS wait on SENDREQ占比高，且LGWR-LNS wait on channel同步高 → 备库 ACK 慢，不是主库 LGWR 本身慢 - 注意：
log_archive_dest_2配了SYNC但备库 I/O 跟不上，就会持续堆积这类等待
检查LOG_ARCHIVE_DEST_2配置是否自相矛盾
一个字母写错，LNS 就不会往备库发日志。常见错误不是参数没设，而是逻辑冲突：
- 错误示例：
LOG_ARCHIVE_DEST_2='SERVICE=standby SYNC DELAY=30'→SYNC要求立刻 ACK，DELAY=30又要求备库延迟应用，Oracle 会静默降级或拒绝提交 - 正确做法：业务允许丢数据 → 改用
ASYNC NOAFFIRM；必须强一致 → 去掉DELAY，确保备库 I/O 能扛住 - 执行
SELECT DEST_NAME, TRANSMIT_MODE, AFFIRM, DELAY FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;核对输出，不是只看 init.ora 里写了什么 -
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)必须存在，否则切换后该路径失效
备库端验证接收与写入能力，LNS卡住常因下游堵死
主库 LNS 在 SENDREQ 上挂住，90% 是因为备库 RFS 没收到、或收到后写归档失败。登录备库逐项验证：
-
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;→ 必须是MOUNT或READ ONLY WITH APPLY，OPEN READ ONLY不接收新归档 -
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 1;→DEST_ID = 1是本地归档目标，ERROR非空（如ORA-00257: archiver error）说明归档目录满或权限不对 -
df -h /u01/arch和ls -ld /u01/arch→ 目录空间和属主/权限必须匹配 Oracle 用户 - 若用 NFS，确认挂载选项含
noac，否则 RFS 写入会因缓存一致性卡顿
真正卡点往往不在主库参数，而在备库归档路径的磁盘、权限、NFS 配置这些“基础但容易被跳过”的环节。
