虚拟机oracle数据库高并发访问导致网络ping包延迟并影响性能

情况描述

OA数据库，在启动应用后，远程执行select语句特别慢，比如查询“select id,form_id from CAP_FORM_RESOURCE where PROPERTY_TYPE = 104”语句没启动应用时1内秒就能出结果，启动应用后需要60多秒，在远程机子上ping数据库服务器包延迟比较高，当应用停止后查询变快，ping数据库服务器也恢复。

虚拟化环境：怀疑CPU不能充分利用

问题处理过程

阶段一：
根据问题描述，检查了数据库服务器cpu、内存、io消耗均不高，数据库的整体性能在正常范围内。由于应用启动后，网络包传输交互明显变慢，ping包返回由原先正常的1s内直接变成五六秒，甚至七八秒，初步断定为网络问题。安排网络工程师检查网络并做了测试均正常。对数据库进行优化、服务器进行网络相关的参数优化，但没有明显的改善。

阶段二：
对远程查询的sql做跟踪：

根据Sql语句跟踪结果，基本没有较大资源消耗，只有在“SQL*Net message from client”这块消耗时间比较久，但这块就是网络问题才会造成，检查网络流量情况，发现网络资源消耗也不高：

阶段三：
由于优化服务器相关网络参数，修改数据库网络参数并进行测试均没有明显改善。OS、网络层面一时也找不到问题，但由于应用启动才造成这个问题，那就用10046跟踪一下应用会话的执行情况，结果发现应用高并发执行了一条sql语句如下：

通过跟踪结果，由于该条语句执行频率较高，所以每核cpu都花费在执行该条语句上：

跟踪结果显示当连接数一下子连上来很多，并且应用一直循环执行该SQL，导致cpu不能及时响应，CPU的等待也造成了该服务器网络的延迟。检查该CPU核数是8个虚拟cpu：

虽然整体cpu耗的不多，但网络延迟的时候，每个cpu使用率都在5%以上，每个cpu都在处理该sql语句了。为了验证，对该语句的涉及的表CIP_MESSAGE_EXTEND进行统计信息删除：
exec dbms_stats.delete_table_stats(‘V3XUSER’,‘CIP_MESSAGE_EXTEND’);
exec dbms_stats.lock_table_stats(‘V3XUSER’,‘CIP_MESSAGE_EXTEND’);–锁定防止重新收集
当统计信息删除后，网络ping包延迟立马下降，业务也恢复正常。但这并不是正常的处理方法，这种处理会影响该sql的执行效率，还需要业务去控制该语句的执行频率和并发。

后续检查awr报告，执行select查询，消耗都在cpu上：

检查消耗cpu的select语句，正是那条执行频率比较高的sql：

1小时总共执行了46633次，基本cpu消耗都是该语句，由于cpu处理性能不足导致网络回包延迟较高，所以也导致了其他语句变慢。

该语句一直循环执行不合适，建议开发修改了该语句的执行频率，修改降低该语句执行频率后ping包延迟恢复正常。