oracle等待事件12——网络上的等待事件

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

--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服务器端根本没有任何性能问题,只是被读取了两次数据。但是客户端就会感觉系统很慢,两次读取间隔太长。所以,低效的应用程序工作方式极有可能就是其原因。

上一篇:病毒纷纭 云安全曲线救网


下一篇:当我们谈深度学习时,我们用它落地了什么?阿里云内容安全功能全新升级