Feedback
Did this article resolve your question/issue?

   

Article

Intermittent delay when reading or writing to a database.

Information

 
TitleIntermittent delay when reading or writing to a database.
URL Nameintermittent-delay-when-reading-or-writing-to-a-database
Article Number000124954
EnvironmentProduct: ODBC, JDBC, ADO.Net
Version: All Supported
O/S: All Supported
Database: All Supported
Application: N/A
Question/Problem Description
How to debug intermittent delays when reading or writing to a database?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
It's important to consider the layers of communication involved when communicating with a database.

Below are some of the most significant layers to consider when debugging for an intermittent delay in communication:

Application
The application is responsible for the activity before sending data via the connectivity driver and after data is received from the connectivity driver.

Application logging that includes timestamps can be helpful when identifying the timing of the application activity in comparison to how long the delays are lasting.

Driver
The connectivity driver is responsible for the activity between receiving from the application and sending over the network -OR- between receiving from the network and sending to the application.

Logging that includes timestamps specific to the connectivity driver in addition to logging network activity on the client side is helpful in identifying time delays pertaining to the application, driver, and network.

Network
When analyzing the network communication, sometimes it is important to log both sides to determine whether the delays are specific to this layer.  Keep in mind, there is hardware and software at each side of the network that handles communication. If a packet is sent from one end and received at the other and there is a significant delay, it suggests a problem with one of the network components.

Database
Database Logging with timestamps will help to analyze the difference in time gaps for activity within the database compared to server-side network communication timing.


It may be helpful to obtain logs with timestamps from most or all of these layers to get a solid picture of where communication delays are occurring.

For any given amount of time for a portion of communication to go from application to database or from database to application, having a set of logs from each layer will allow for identifying where in the communication a delay is occurring. It is important to note that in any single log, it will only help to identify which side of the layer a delay is occuring.

For example, a log of the driver will show when an out-going action was sent and when a returning action is received.  A delay between a sent and received action suggests the delay is  on the network or database side.  A delay between receive and send suggests a delay on the application or possibly driver.

Having logs between two adjacent layers will help to confirm further which layer may be responsible for any delays. So, if any particular layer is suspected of delays, it is ideal to obtain logs from that layer and each adjacent layer on both sides.  For example,  If the driver is suspected of delays in communication, gather logs from the application, driver, and network. It should be clear from that analysis where to look next if the source of delay is not identified.

Here are some suggested logging types for each of the driver and network layers:

Driver

ODBC:  ODBC Tracing
JDBC:  Spy tracing
ADO.Net:  ADO.Net tracing

Network

Snoop packet tracing (obtained from Progress DataDirect)
Wireshark (https://www.wireshark.org/)


 
Workaround
Notes
Last Modified Date2/21/2020 9:36 PM
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.