locked
Strange Timeout problem RRS feed

  • Question

  • hi,

    i hope this is the right forum to place my question. If its not please move it to where it belongs to.

    Here is my strange timeout-problem:

    I've created some .NET services which are executing many different sql-statements (depending on what's to do).
    Most of the statements (Inserts, Updates, Selects) are working fine without any performace or timeout problems.
    These statements are only affecting one row.

    But I have one scheduled task which has a different sql-statement from the others.
    This has to Update many rows at once:

    UPDATE Document SET State=32 WHERE DeliveryId = 'B90A994D-0BF7-4D77-8ADC-B7B7BED18182'

    Sometimes this Update executes without problems, sometimes it runs into a TimeoutException (after 30 seconds)
    (System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.)

    But when the timeoutException occurrs I execute right after that almost the same statement (just another state because of this error)

    UPDATE Document SET State=31 WHERE DeliveryId = 'B90A994D-0BF7-4D77-8ADC-B7B7BED18182'

    and this always works fine an needs about 90 seconds (!)...


    I just don't understand why it sometimes run into a Timeout afer 30 seconds and sometimes he can execute it within 90 seconds.

    I checked this with the SQLProfiler and the statements are always executed (only 30 seconds, if Timeout occurred) 
    so there shouldn't be a connectionproblem.

    Could anyone help me here?

    Thanks a lot!
    Tobi



    Thursday, December 6, 2012 3:34 PM

Answers

  • I'm using a OR-Mapper-tool Lightspeed which is using a SQLCommand in the background. The two statements are executed right after the other and I'm using the same unitOfWork (thats the object which creates and executes my statements ). So this has to be the same timeout-value.

    Don't count on that. Of course, if you are not creating the SqlCommand yourself, you are not in control. In any case, the only thing that could matter from an SQL perspective is if your UPDATE statement fires a trigger that produces a result set within 30 seconds. Most client API turns off the timeout if they have seen data within the time frame.

    Assuming that this is not the case, the question of different timeout lengths is entirely client-side dependent. Well, SQL Server has to acknowledge the Attention signal, and a rollback of many statements could take a long time. But that sounds unlikely in this case.

    'same but easier to readUPDATE Document SET State = 32 WHERE
    (
         (
              ((Document.State = 20 OR Document.State = 23) AND Document.LetterClosedDate IS NOT NULL)
              AND Document.DeliveryTypeNo = 10
         )
         AND Document.SendLetter = 1
    )

    usually it takes about 10 seconds (too long right ;)) and sometimes it takes over 30 seconds...


    You would need a composite index on the columns in the WHERE clause, with State as the last column.

    It is obviously you have a blocking problem in this database, and you need to track down the blocking statement(s). Of which the UPDATE above with DeliveryID as column could be one of the culprits.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    • Proposed as answer by Barry Marshall Thursday, December 13, 2012 5:34 PM
    • Marked as answer by Iric Wen Monday, December 17, 2012 6:34 AM
    Friday, December 7, 2012 11:29 AM

All replies

  • You should be able to adjust the timeout in the .NET code. This question may be more appropriate for the C# forums.
    Thursday, December 6, 2012 3:41 PM
  • thanks for your quick answer.

    i can adjust the timeout in my code but this is not the solution. Why am i getting sometimes a timeout after 30 seconds and then i can execute a statement which runs about 90 seconds?

    can you tell me the difference?

    what is the reason in MSSQL-Server to throw a timeout-exception? execution-time can't be the reason...

    Thursday, December 6, 2012 3:56 PM
  • I note this statement in yor original post:
       "This has to Update many rows at once:"

    Have you checked with SSMS that the updae is not being blocked by other processes?

    Note also: The timeout is managed from DOT NET, so it restarts for evey confirmation coming back from SQL server, not only on completion of the whole batch.


    "Premature optimization is the root of all evil." - Knuth

    If I provoked thought, please click the green arrow

    If I provoked Aha! please click Propose as Answer

    We are here to learn, to share knowledge, and to earn points; all in about equal measure.

    Thursday, December 6, 2012 4:02 PM
  • what is the reason in MSSQL-Server to throw a timeout-exception? execution-time can't be the reason...

    MSSQL Server does not raise any exception! The timeout is client-side only. Was it up to SQL Server only, the statements would wait forever.

    Why you get different behaviour, I don't know, but one guess is that the SqlCommand object in the code where you set the state to 32 has CommandTimeout set to 0 or a higher value, and the other SqlCommand object has not.

    In any case, 30 or 90 seconds seem excessive. It seems that there is a blocking problem. You do have an index on DeliveryID, don't you?


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Thursday, December 6, 2012 11:02 PM
  • Could you show us your execution plan? Maybe you just need an index or reorganize if they have one
    Thursday, December 6, 2012 11:13 PM
  • Hi Tobias,

    30s is a lot of time. Ideally, SQL should be completed in millisecond.  Any SQL that runs in seconds should be closed examined. I think you need to switch your attention from timeout to improving the performance.

    I guess there is no index for your DeliveryId field. Am I right? If this is the case, you can just add an index for the filed and the issue will be solved completely.

    Thanks,

    Kevin Gao

    http://livechat.comm100.com/livesupport/ for your websites

    MCSD, MCDBA, MBA

    Friday, December 7, 2012 3:45 AM
  • Could you show us your execution plan? Maybe you just need an index or reorganize if they have one

    I told my customer to log the "Showplan" with his sqlprofiler. Hopefully the timeout will occur again today so that i can check this. I can't reproduce the timeout on our testmachines...

    //Why you get different behaviour, I don't know, but one guess is that the SqlCommand object in the code where you set the state to 32 has CommandTimeout set to 0 or a //higher value, and the other SqlCommand object has not.

    I'm using a OR-Mapper-tool Lightspeed which is using a SQLCommand in the background. The two statements are executed right after the other and I'm using the same unitOfWork (thats the object which creates and executes my statements ). So this has to be the same timeout-value.

    // It seems that there is a blocking problem. You do have an index on DeliveryID, don't you?

    hm...you are right. i just checked it on the server and there are several indexes but non for the deliveryId column...thanks for this hint! I will create an index if my customer will allow me that ;)

    But even if the index will speed up the hole statement-execution I have another statement which usually needs 1-2 seconds that also runs into a timeout from time to time (one day it works fine, another day it takes more than 30 seconds..-->Timeout)

    I just saw, that i didn't post the whole statement:

    here is the correct one:

    'created by my OR-mapper

    exec sp_executesql N'UPDATE Document SET State = @p2 WHERE (Document.DeliveryId = @p0 AND Document.State = @p1)',N'@p0 uniqueidentifier,@p1 int,@p2 int',@p0='3E9AFBD9-6360-4551-8CCE-1D4E0C700F74',@p1=32,@p2=30 'same but easier to read UPDATE Document SET State = 30 WHERE (Document.DeliveryId = @p0 AND Document.State = '3E9AFBD9-6360-4551-8CCE-1D4E0C700F74')


    This statement usually takes only 1-2 seconds (the state-column has an index)...

    here is the second statements which cause a timout exception:

    'original statement from my OR-Mapper

    exec sp_executesql N'UPDATE Document SET State = @p4 WHERE ((((Document.State = @p0 OR Document.State = @p1) AND Document.LetterClosedDate IS NOT NULL) AND Document.DeliveryTypeNo = @p2) AND Document.SendLetter = @p3)',N'@p0 int,@p1 int,@p2 int,@p3 bit,@p4 int',@p0=20,@p1=23,@p2=10,@p3=1,@p4=32

    'same but easier to read

    UPDATE Document SET State = 32 WHERE ( ( ((Document.State = 20 OR Document.State = 23) AND Document.LetterClosedDate IS NOT NULL) AND Document.DeliveryTypeNo = 10 ) AND Document.SendLetter = 1 )

    usually it takes about 10 seconds (too long right ;)) and sometimes it takes over 30 seconds...



    • Edited by Tobias Koller Friday, December 7, 2012 9:31 AM
    • Proposed as answer by Barry Marshall Thursday, December 13, 2012 5:34 PM
    • Unproposed as answer by Barry Marshall Thursday, December 13, 2012 5:34 PM
    Friday, December 7, 2012 8:14 AM
  • I'm using a OR-Mapper-tool Lightspeed which is using a SQLCommand in the background. The two statements are executed right after the other and I'm using the same unitOfWork (thats the object which creates and executes my statements ). So this has to be the same timeout-value.

    Don't count on that. Of course, if you are not creating the SqlCommand yourself, you are not in control. In any case, the only thing that could matter from an SQL perspective is if your UPDATE statement fires a trigger that produces a result set within 30 seconds. Most client API turns off the timeout if they have seen data within the time frame.

    Assuming that this is not the case, the question of different timeout lengths is entirely client-side dependent. Well, SQL Server has to acknowledge the Attention signal, and a rollback of many statements could take a long time. But that sounds unlikely in this case.

    'same but easier to readUPDATE Document SET State = 32 WHERE
    (
         (
              ((Document.State = 20 OR Document.State = 23) AND Document.LetterClosedDate IS NOT NULL)
              AND Document.DeliveryTypeNo = 10
         )
         AND Document.SendLetter = 1
    )

    usually it takes about 10 seconds (too long right ;)) and sometimes it takes over 30 seconds...


    You would need a composite index on the columns in the WHERE clause, with State as the last column.

    It is obviously you have a blocking problem in this database, and you need to track down the blocking statement(s). Of which the UPDATE above with DeliveryID as column could be one of the culprits.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    • Proposed as answer by Barry Marshall Thursday, December 13, 2012 5:34 PM
    • Marked as answer by Iric Wen Monday, December 17, 2012 6:34 AM
    Friday, December 7, 2012 11:29 AM
  • ok, thanks for your answer!

    I will check the statements again and may create new indexes especially for this statement.

    I also asked a question about this timeout in the lightspeed-forum.

    Lightspeed Forum

    Maybe they can tell me what lightspeed exactly does.

    Tobi

    Friday, December 7, 2012 11:56 AM