网络上的相关等待时间有如下几种：

--SQL*NET message from / to client

--SQL*NET more data from /to client

--SQL*NET message from /to dblink

--SQL*NET more data from / to dblink

这些事件大部分视为Idle（空闲）事件，所以分析性能问题时一般不予考虑。但某些情况下，这些事件对于分析性能下降原因可提供决定性线索。这些事件与性能问题相关的情况如下：

1）网络速度缓慢时

如果等待上述事件的时间异常地高，就应该怀疑网络速度。客户端和DBMS之间的网络通信若是存在问题，就对SQL*NET message from /to client、SQL*NET more data from/to client 事件的等待可能增加。这时，应该和系统管理员沟通后，需要对网络层进行检测工作。

如果在RAC环境下，与GC(global cache) 相关的平均等待时间过长，同样有必要检测网络性能。RAC上的缓存同步基本上是通过网络实现的，所以网络结构存在问题时，这个将直接影响性能。不仅是网络速度，还要检查数据交换设备是否设定恰当。

2）SQL执行次数（execute count）异常的过高时。

执行次数（execute count）过多时，客户端和DBMS间的网络通信频繁地发生，因此网络相关的等待时间可能会延长。这时，oracle需要等待从客户端发送的响应，所以等待SQL*NET message from  client 或 SQL*NET more data from client 事件。特别是整个等待时间中，如果SQL*NET more data from client 占据着相当比重的等待时间，就应该怀疑过多执行次数引起的系统性能下降。

解释上述测试结果时，需要留意如下几点。第一，V$SYSSTAT视图或V$SESSTAT视图的execute count统计值不是从客户端出发，而是从DBMS角度上出发计算的。即，也包含了通过recursive SQL执行的次数，因此递归调用（recursive call）较多的情况下，有时execute count值不能反映客户端上执行次数。case1 和 case2的execute count值是227（227约等于122的两倍），实际上出现相同的值也是因为这个理由。第二，SQL*plus上，每次执行SQL语句都执行DBMS_OUTPUT.GET_LINES.所以execute count值显示为执行次数的两倍。

如果想从客户端角度执行次数，就应该同时考虑 parse count（total）统计值和 execute count统计值，以上的此时虽然execute count统计值相同，但在case2中pase count（total）统计值非常小。即，可以推测case1是每次重复执行SQL语句的情况，case2是将相同量的工作一次性在PL/SQL上处理的情况。所以execute count 统计值和parase count（total）统计值如果相似的增长。则可以判断正在采用一次分析后执行一次的典型低效的处理方式。客户端角度上执行次数多时，因网络通信伴随的等待时间，客户所感觉到的响应时间可能大幅下降。这时，尽量利用PL/SQL排毒处理（array peocessing）来减少DBMS调用。

3）应用程序的实现方式存在问题时

如果应用程序的实现方式上存在问题，与DBMS维持着连接状态，不必要的等待时间较多，可能会使SQL*NET message from client 等待时间会较长。用户角度上说，用户很可能认为应用程序的响应速度缓慢。

例如：应用程序从oracle拿来一个数据后执行复杂的计算（需要花费很长时间），然后再从oracle拿来一个数据后再执行另外的工作。在oracle服务器端根本没有任何性能问题，只是被读取了两次数据。但是客户端就会感觉系统很慢，两次读取间隔太长。所以，低效的应用程序工作方式极有可能就是其原因。