sql*net message from client高占比通常不用管，因其是空闲等待，表示会话已执行完sql并等待客户端下一条命令；只要未进入top 5 timed foreground events且avg wait ms低（如
AWR报告里出现网络类等待，基本不是网卡或交换机问题，而是数据库与客户端交互逻辑或配置出了偏差——直接查SQL*Net message from client和SQL*Net more data to client这两项就够了，其他网络等待多数是干扰项。
为什么SQL*Net message from client高占比通常不用管
这个等待发生在会话挂起、等客户端发下一条命令时，本质是“空闲等待”。只要它没进AWR的Top 5 Timed Foreground Events，就说明数据库本身没卡住，只是应用端节奏慢或没发请求。
- 常见于报表导出、ETL工具分页拉取、Java应用未启用连接池等场景
- 如果
SQL*Net message from client平均等待时间（Avg Wait ms）极低（ - 真正危险的是
SQL*Net more data to client——它表示数据库已准备好数据，但客户端收不全，常因网络缓冲区溢出、TCP窗口缩窄或中间设备限速
如何用AWR交叉验证是否真有网络瓶颈
单看等待事件容易误判。必须把SQL*Net more data to client和Load Profile里的Execute Count、Parse Count (hard)以及SQL Statistics中Rows Processed per Exec一起看：
- 若
SQL*Net more data to client等待飙升，同时Rows Processed per Exec也大幅上升（比如从100行/次涨到5万行/次），大概率是应用改了批量fetch逻辑，不是网络问题 - 若该等待高，但
Execute Count和Rows Processed都正常，再查v$session_wait实时确认：执行SELECT * FROM v$session_wait WHERE event = 'SQL*Net more data to client' AND state = 'WAITING'，看是否集中在少数几个长事务会话上 - 注意
SQL*Net break/reset to client：若它在Top 5里且time_waited持续增长，说明客户端异常断连，可能触发大量重连和软解析，需查应用日志而非网络设备
哪些网络等待才真要下到OS层查
只有两类值得立刻切到操作系统验证：
-
SQL*Net more data to client+SQL*Net break/reset to client同时高：用netstat -s | grep -i "retransmit\|reset"查TCP重传和RST包数量；用tcpdump -i eth0 'port 1521 and (tcp-retransmission or tcp-rst)'抓包确认是否被防火墙或负载均衡器拦截 -
SQL*Net message from client平均等待突增至>100ms且集中在某几个会话：用strace -p <sid> -e trace=recvfrom,sendto</sid>跟踪对应Oracle进程的socket调用，看是否卡在recvfrom系统调用上——这说明客户端确实没发数据，问题在远端
最容易被忽略的一点：AWR里的网络等待全是“前台会话”统计，完全不反映后台进程（如DBWR、LGWR）的网络行为。如果怀疑监听器或TNS配置有问题，必须用lsnrctl services和tnsping单独验证，AWR给不出线索。
