January 27, 2011 at 9:03 am
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.
January 27, 2011 at 9:31 am
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.
January 27, 2011 at 11:00 am
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.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply