SQL*Net message from client 是空闲等待，表示会话已返回结果并等待客户端下一条命令；在OLTP中占60%~80%属正常，过低反提示数据库资源瓶颈。
SQL*Net message from client 在 AWR 里意味着什么
这个等待事件本身不表示数据库出问题，而是说明会话已执行完 sql、返回结果，并正在等客户端发下一条命令。它被 oracle 归类为 idle 类等待，在 oltp 系统中占总等待时间的 60%~80% 属正常；如果低于 30%，反而要怀疑是不是数据库 cpu 或 i/o 被卡住，导致根本没机会进入这个“空闲等”状态。
AWR 报告里的 SQL*Net message from client 高占比，不能直接等同于“网络慢”，但它是排查网络延迟的第一入口——因为只有当网络链路或客户端处理变慢时，这个等待才会被拉长、堆积，甚至在 Top 5 Timed Events 中突显出来。
怎么确认是真网络延迟，而不是应用层拖慢
先排除常见干扰项，再定位真实瓶颈：
- 检查客户端是否在做耗时操作：比如 Java 应用收到结果后执行复杂对象映射、日志写入、跨服务调用，这些都发生在网络往返之后，但会让
SQL*Net message from client看似“等了很久” - 确认连接方式：直连数据库（无中间件）比走 WebLogic/Tomcat/Druid 连接池更易暴露真实网络耗时；若用了连接池，需额外查池内连接复用率和获取等待
- 看
v$session的STATUS和SQL_ID：处于INACTIVE状态且EVENT = 'SQL*Net message from client'，同时LAST_CALL_ET > 300（秒），说明该会话挂起超 5 分钟，大概率不是数据库问题 - 对比同网段其他服务：比如用
tnsping测目标实例、sqlplus /@tns_alias执行简单语句（SELECT 1 FROM DUAL），记录响应时间基线
从 AWR 报告里提取有效线索
不要只盯着 Top 5 Timed Events 的百分比，重点看这几处：
-
Time Model Statistics中的DB time与DB CPU差值：如果 DB time 远大于 DB CPU（比如差值占 70%+），且SQL*Net message from client是主要构成项，说明大量时间花在“等客户端”，而非数据库内部 -
Top Sessions部分：找出SQL*Net message from client累计等待时间最长的SID，再查v$session对应的MACHINE和PROGRAM，确认是哪个应用服务器或客户端 IP 在拖慢节奏 -
SQL ordered by Elapsed Time里执行快但调用频次极高的语句（如单条SELECT COUNT(*)每秒跑几十次）：这类语句本身不重，但网络往返放大了延迟影响，容易让SQL*Net message from client总量飙升 - 如果报告中同时出现高
SQL*Net more data to client或SQL*Net break/reset to client，基本可断定是大结果集传输或异常中断，和网络带宽/MTU/防火墙策略强相关
真正要测网络延迟，别只靠 AWR
AWR 是间接证据，真要量化网络延迟，得结合 OS 层和 Oracle 客户端工具：
- 在应用服务器上跑：
ping -c 10 <db_host></db_host>和mtr --report <db_host></db_host>，关注丢包率和第 3~5 跳延迟突增（常是防火墙或负载均衡器） - 用
sqlplus开启 trace：set autotrace traceonly stat+ 执行语句，观察elapsed和cpu的差值，差值大且稳定，就是网络或客户端处理拖慢 - 启用 Oracle Net trace（在
sqlnet.ora加TRACE_LEVEL_CLIENT = 16），抓到的.trc文件里能精确看到每次NSPM（network send/receive）耗时 - 注意：
SQL*Net message from client的等待时间，Oracle 只统计“从结果发完到下条命令到达之间”的时长，不包含 TCP 建连、SSL 握手、DNS 解析这些前置开销——这些得靠 Wireshark 或tcpdump抓包确认
最常被忽略的一点：很多 DBA 看到 AWR 里这个等待高就去调数据库参数，其实它根本不受 db_file_multiblock_read_count 或 sga_target 影响。真正该动的是应用连接方式、网络路径、结果集大小控制——数据库在这儿只是个“听话的邮局”，别让它背锅。
