Timeout exceptions during execution of stored procedures

  • Thread starter Thread starter tonci.tomic
  • Start date Start date
T

tonci.tomic

I have windows service running on win2000 and client applications on
local network connected to service via remoting.
Service acts as interface to MSSQL 2000 database and it uses Microsoft
Data Application Block.
Every few days data block throws timeout exception during the insert
(and very rarely even during select). After that every subsequent
insert from any client, even from client residig on the same machine
as service, throws the same exeption.

There is no database activity on the server, CPU usage is cca 5%, and
it seems like nothing is going on. Database is small and there is
plenty of disk space (SCSI discs).

I tried to restart service, it didn't help. Problem persists for hour
or two, than simply disappeares, so system continue to work as it
nothing happened.

During one of these blocks I used query analyzer to insert some data
into database "manually". I run insert SQL statement and it succeeeded
after 45 seconds. Magically, after that successful insert, system
recovered and all clients continued to work correctly.

I increased timeout from 30 secs to 60, but I only succeeded to
increase working periods. Strange timeouts now popup cca once in a
weak.
Of course, insert cmd from query analyzer finish after more than 60
secs and that somehow fix the problem.

Does anyone have some hint what's going on? It is veeery hard for me
to reproduce the problem. Should I increase timeout to 120 secs? 500
secs?
It is hard to explain to users that, from time to time, they should
wait 5 minutes for some simple insert statement to complete.

Thanx
 
There are two timeouts to deal with in ADO.NET. The first is the connection
timeout; the second is the command timeout. Both need to be set if you have
activity that will take you beyond the timeout value of either.

If you find that simple queries are taking too long, you may need to look at
indexing strategy on the table, along with other factors (triggers, etc.).

If you can watch the system (SQL profiler) until it bombs, you will get a
better idea of what is happening at the time. Perhaps you will find some code
with an exclusive lock on a select, etc.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Back
Top