Last Known Successful DBCC CHECKDB

Question

I understand that looking at DBCC PAGE is supposed to show me the last known good DBCC CHECKDB but I am not seeing this work correctly.

I have a database that I know is corrupted. If I run DBCC CHECKDB the errors are displayed as expected (see below).

CHECKDB found 0 allocation errors and 1 consistency errors in table 'Blah'
   (object ID 251147940).
Msg 2508, Level 16, State 3, Line 1

When I run the below to evaluate dbi_dbccLastKnownGood, I get the time that the CHECKDB was just run down to the second.

DBCC PAGE ('Blah', 1, 9, 3) WITH TABLERESULTS;

I've read Paul Randal's information, and from that, it looks like I'm doing/reading this correctly. Has anyone seen this before and if so, any thoughts on working around it?

Here is a complete sample of the error. I am getting 12 of these for different tables.

    Msg 2508, Level 16, State 3, Line 1
The In-row data RSVD page count for object "Mailings", index ID 0, partition ID 16459231395840, alloc unit ID 16459231395840 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
CHECKDB found 0 allocation errors and 1 consistency errors in table Mailings' (object ID 251147940).

Answer 1

_{Community wiki answer:}

From CHECKDB From Every Angle: When did DBCC CHECKDB last run successfully? by Paul Randal:

One of the new features we put into SQL Server 2005 was storing the last time that DBCC CHECKDB completed successfully (called the last-known good time). It’s the time that the DBCC CHECKDB started, not completed.

What does successfully mean? This is the catch – if DBCC CHECKDB runs to completion then it considers that a successful run – EVEN if it found some corruptions. However, the last-known good time is ONLY updated if there were NO corruptions found. Slightly confusing I know.

Does seem somewhat contradictory, but I agree it sounds like this is not expected behaviour for that field to be updated if errors were reported.

On the other hand, your examples are quite minor issues, easily fixed by running DBCC UPDATEUSAGE so maybe SQL Server regards that as a successful run.