Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When I run DBCC CHECKDB, I get a slew of error messages like this:

Table error: object ID 2020918271, index ID 1, partition ID 72057594196590592, alloc unit ID 72057594190233600 (type In-row data), page (4:129574), row 0. The record check (valid UDT column) failed. The values are 3 and 0.

Right now I'm just trying to understand what this error means and how serious it is - it seems to be some checksum-related error and probably not that severe. Recent backups seem to have the same problem, but it's not a big deal either way because the data can be recreated from other sources.

Anyway, I'm trying to get to the bottom of this, maybe understand which rows are corrupted, if there's any particular pattern to it. When I run DBCC PAGE to see what's in there, such as the following statement:

DBCC PAGE('MyDB', 4, 129574, 3)

It shows nothing. Nada. Zip. Just the standard:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

But no error and no page data. In fact, every single error that's coming out of CHECKTABLE has a file/page number for which I get this output from PAGE.

I'm also seeing the following error from the CHECKTABLE output, but only sporadically:

Table error: Object ID 2020918271, index ID 1, partition ID 72057594196590592, alloc unit ID 72057594190233600 (type In-row data). Page (4:129575) was not seen in the scan although its parent (4:129977) and previous (4:129574) refer to it. Check any previous errors.

It looks like it might be related, but I'm not really sure how. The UDT can be relatively large (about 5 KB), so maybe it's split across pages and one of the pages is missing? That's just a wild guess, though.

The number of errors coming out of CHECKTABLE also makes it look as if the entire table is like this, but I know that's not the case, because I can read the data just fine. In fact, there's an automated process that runs every day that will, over time, read just about all of the data in this table, and it hasn't reported a single error. Also if I run DBCC PAGE on one of the parent pages (which do exist, even though the "previous" pages don't), I can get the key columns, and I can SELECT all the data for all surrounding keys without any error.

Can anybody tell me what's going on here? Does it make sense for DBCC CHECKTABLE to be giving me these errors when the pages referred to don't even exist? Is it possible that CHECKTABLE itself is emitting spurious errors?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

Did you turn on trace flag DBCC TRACEON(3604)? Otherwise oll DBCC PAGE output goes to errorlog only.

share|improve this answer
    
Right, that was it. I'm sure that was stored in my memory somewhere too, I've done it before... Mondays. I don't suppose you know if the row number from CHECKTABLE corresponds to the slot number in the trace output? Because if it is, then the data is completely fine, and these errors still make no sense. –  Aaronaught Feb 22 '10 at 18:42
    
Afaik Row 0 in dbcc checktable is slot 0 on the dbcc page –  Remus Rusanu Feb 22 '10 at 18:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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