SQL Server 2005 sp3 Standard on 64-bit Windows Server 2008

inconsistently receiving an error that seems to indicate corruption

select * 
from some_table 
where text_field like ‘%the fox did not go into the hen-house %’

sometimes, but not always, this and similar queries will generate the following error

Msg 7105, Level 22, State 6, Line 1
The Database ID 11, Page (1:990063), slot 4 for LOB data type 
node does not exist. This is usually caused by transactions 
that can read uncommitted data on a data page. Run DBCC CHECKTABLE.

the severity level of 22 causes the connection to be broken

the data has long ago been committed

the table has only two indexes, neither of which list the text field

the database is in isolation level read committed snapshot

the database is being mirrored

the error is being generated by simple select queries, not by update queries

the error showed up for the first time about a month ago, one occurrence; second occurrence was twelve days ago; third and fourth occurrences were yesterday; today there have been two new occurrences

the queries are being run without hints, no use of NOLOCK

I have repeatedly run dbcc checkdb and dbcc checktable, and so far in a half dozen tries, no errors noted by either command; these commands take much longer to run than expected .. on similarly sized databases, dbcc checkdb will run in under a minute, but for this one, it takes almost ten minutes

the error comes and goes, meaning sometimes I run the query and it returns quickly with all expected information, and other times running the query returns the error

the network/server engineers were asked to review the associated SAN disks, and report that there are no issues

what could be the root cause of this issue? could it be hardware? if so, how can I guide the engineers? if not hardware, what else could it be?

1 Answer 1


Read what the bloke (Paul Randal) who wrote some of the associated SQL Server code says

And logged on MS Connect

And have you ran DBCC CHECKDB (KB 2015760)?

  • thanks, that seems to be the issue, that the database is in read committed snapshot isolation level and the table has a LOB field .. via tracing, I could see that only when an insert was affecting the LOB field would a select query fail .. KB962209 says the solution is to go from sp3 to sp3 cu2, and for a workaround I'll ask the user to use the (readcommitted) hint
    – Oliver
    Dec 14, 2010 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.