November 10, 2011 at 1:46 pm
Iulian -207023 (11/10/2011)
Thank you Ninja's_RGR'us and GilaMonster for the very good examples: charts with aproximate values and session tables.Jared I don't think that NOLOCK can generate the timeouts you mention but to be sure it might worth checking the locks with sp_lock, sp_who and sp_who2.
Regards,
Iulian
For me, it will show up as a timeout error on the FreeTDS side when there is a read error. Error handling sucks in FreeTDS. The Read Errors would come from a page split or a record being deleted as the NOLOCK query is running.
Thanks,
Jared
Jared
CE - Microsoft
November 10, 2011 at 2:02 pm
Page splits might be due to index fragmentation
Iulian
November 10, 2011 at 2:20 pm
Iulian -207023 (11/10/2011)
Page splits might be due to index fragmentationIulian
Actually, I believe that is reversed... index fragmentation comes from page splits. However, that's besides the point. I'm sorry I'm not being clear. I am referring to the Read Errors section of this article: http://sqlblog.com/blogs/andrew_kelly/archive/2009/04/10/how-dirty-are-your-reads.aspx
Jared
Jared
CE - Microsoft
November 10, 2011 at 4:16 pm
Trying to clear up the air :
You get the data movement error... when there's data movement. That means pagesplit or possibly if a record is moved to another page because the PK is updated (I never tested that specific case but it makes sense in theory from what I know of the internals).
So is there any one left who still needs help with this issue?
November 10, 2011 at 5:59 pm
Ninja's_RGR'us (11/10/2011)
Trying to clear up the air :You get the data movement error... when there's data movement. That means pagesplit or possibly if a record is moved to another page because the PK is updated (I never tested that specific case but it makes sense in theory from what I know of the internals).
So is there any one left who still needs help with this issue?
Case closed 😉
Jarede
Jared
CE - Microsoft
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply