Database Troubleshooting and Slow Network Speed Analysis Guide

Database Troubleshooting for Slow Network Speed Issues

Generally, databases, applications, and networks operate within separate branches of IT architecture. Although database troubleshooting is typically performed by DBAs, network engineers can still analyze packet capture data to identify if a slow network speed is truly the root of the problem. When faced with “slow network speed” complaints, it’s crucial to confirm the actual issue. The following steps guide you through the process of database troubleshooting and slow network speed analysis, helping to verify and resolve the underlying causes effectively.

More information

Working process:

For database issues, follow these steps:

1. When a “slow network response” is suspected, ask the following questions:

• Is the problem local or global? Is it just in the remote office or does it happen in the center as well? If the problem is network-wide, it is not a WAN bandwidth issue.
• Does the problem occur for all clients? If it only occurs for certain users, it may be caused by certain applications they are running.
• Is the communication link between the client and the server overloaded? What application is causing the overload?
• Are all applications slow, or are they slow only for applications that use a specific database? Are the PCs old, or are the servers running out of resources?

1. After clarifying the above problems, start troubleshooting:
   1. Open Wireshark and start capturing packets. You can connect the peer port to a PC, server, VLAN, or a router connected to a remote client.
   2. View TCP events in expert info. Do these events occur in the entire communication link, or a specific IP address, or a specific TCP port? This operation can help locate the problem and verify whether it occurs in a specific link, server, or application. When testing data streams connected to the Internet, you may get many retransmissions and duplicate ACKs sent to sites or mail servers (and the like). Within an organization, the retransmission range should be between 0.1 and 0.5 percent. When connected to the Internet, it may be much higher.
2. When you see a problem on the network, follow the troubleshooting steps in the previous pictures to solve it. However, some network problems may affect database operations. In the following example, you can see that the round-trip delay between the client and server communication link is 35 to 40ms.
   1. We look at TCP stream 8 (1), and the connection starts with TCP SYN/SYN-ACK/ACK. As shown in the following figure (2). You can see that the entire connection took 371 packets (3).

2. The connection continues, and it can be seen that the time interval between the DB request and the response is about 35ms.

3. Since there are 371 round trip messages, 371 x 35 ms is about 13 seconds. In addition, some retransmissions may cause delays, so users may have to wait 10 to 15 seconds to query the database.
4. In this case, you should discuss with the DBA how to significantly reduce the number of messages transmitted on the network, or change the terminal server or network access method.

1. Another possible problem is that the capture file shows a software problem. In the screenshot below you can see 5 retransmissions (1) and the client opens a new connection (3). It looks like a TCP problem but it only happens in a specific window in the software. This is simply because a software process has stopped running and TCP is therefore unable to respond to the client (2).

More suggestions:

Right-clicking the database client and server conversation message will open a window that helps DBAs view network problems. When encountering latency issues, for example, when accessing the Internet via a mobile phone, the database client to server communication may be inefficient. You may need to switch access methods.

It is important to understand the working model of the database. If the client is connecting to the database server, and the database server is using files shared from another server, the client-server may be working fine, but the problem may be in the file sharing between the database server and the file server. Make sure you know all the dependencies before you start testing.

Most importantly, maintain a good relationship with your DBA.