Stump on why this statement ever performs well 1 day 5 minutes next day a second.

  • shaun.stuart,

    I ment a column...for example by taxid, customerid or another unique value that has an index.

    The following script was the one they ran to rebuild the index.

    EXEC sp_updatestats 'resample'

    EXEC sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"

    Needless to say that the to results where unsuccessful. The success was that the issue has now been submited to programming.

    Thanks again everyone.

  • Please see the attached actual execution plans. One useing the address search and the other useing a taxid search.

    The address search tool around 5 minutes the taxid search took about 1 second.

    Thanks again. I just wanted to add that last bit of information that was asked for on this post.

  • Carlton B Ramsey (1/27/2011)


    Please see the attached actual execution plans. One useing the address search and the other useing a taxid search.

    The address search tool around 5 minutes the taxid search took about 1 second.

    Thanks again. I just wanted to add that last bit of information that was asked for on this post.

    Now that's easy to answer:

    The taxid query used a nonclustered index seek whereas the address search needed a table scan due to the non-sargable WHERE clause.

    So it looks like the source is a dynamic query that'll use different columns if needed.

    To answer your original question: the reason for being slow on one day and fast on the next day might be caused by an alternating dynamic query.



    Lutz
    A pessimist is an optimist with experience.

    How to get fast answers to your question[/url]
    How to post performance related questions[/url]
    Links for Tally Table [/url] , Cross Tabs [/url] and Dynamic Cross Tabs [/url], Delimited Split Function[/url]

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply