EarnestGoesWest (9/27/2013)

---

Hi,

I've recently implemented a new DBCC INTEGRITY check process running a combination of CHECKDB (for the smaller databases) and CHECKTABLE for larger - spread over a few days.

During my testing of the CHECKTABLE element, I've noticed that the CHECKTABLE does not always report the integrity errors. :w00t:

If I repeatably run the check, about 1 in 4 times it reports no errors at all, the other times it does - see below :-

ERRORS :-

ErrorLevelStateMessageText

8928161Object ID 2105058535, index ID 0, partition ID 72057594038779904, alloc unit ID 72057594039828480 (type In-row data): Page (1:79) could not be processed. See other errors for details.

89391698Table error: Object ID 2105058535, index ID 0, partition ID 72057594038779904, alloc unit ID 72057594039828480 (type In-row data), page (1:79). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 29493257 and -4.

2593101There are 911 rows in 11 pages for object "CorruptTable".

8990101CHECKTABLE found 0 allocation errors and 2 consistency errors in table 'CorruptTable' (object ID 2105058535).

No ERRORS :-

ErrorLevelStateMessageText

2593101There are 911 rows in 11 pages for object "CorruptTable".

I should add, for the test, I manually corrupted the "test" database by manually editing the MDF files on a particular value. This issue is occuring on SQL2008(SP2), on my SQL2012 instance it seems to behave itself as expected. I appreciate that this could because this is a forced corruption, but surely a corrupt database is still a corrupt database by whatever means.

Has anyone else seen this behavour?

Thanks