Problem Description
An engineer from a development center reported slow oracle database connections in the testing environment, affecting system applications. After contacting the database administrator, they confirmed the database was functioning normally. The engineer then suspected that network slowness or lag might be the cause and escalated the issue to the network team.
Problem Analysis
Following initial communication, it was established that the fault occurred consistently under specific system operations (which makes such issues easier to analyze than sporadic ones). Basic operations were conducted, including long ping tests to confirm network latency and jitter, both of which were normal. Next, a packet capture was suggested during the complete reproduction of the problem:
tcpdump -i 5 -en host x.x.x.x -w test.pcap
As shown in the figure, there were not many data interaction packets, and the issue was relatively clear: the TCP three-way handshake (1-3) was normal, and the round-trip network latency was acceptable. After establishing the connection, data exchanges—including Request and Response—were mostly normal until packets 19-20. The issue began with client packet 21 (Request), where the server did not respond promptly. It only acknowledged packet 21 with packet 22 (ACK), while the response data was not received until packet 23, resulting in a total delay of 7 seconds by the time the client received it.
TCP Flow Graph – Time Series
The interval between packets 22-23 was clearly illustrated in the graph.
Conclusion
Based on the above analysis, the issue was primarily determined to be with the Oracle database server. This finding was reported back to the database administrator, who conducted a detailed examination of the Oracle logs, confirming that a DNS resolution problem during Oracle database execution was causing the slow response. After subsequent adjustments to the system configuration, business operations returned to normal.