Why does DBCC CHECKTABLE WITH TABLERESULTS only report Error 8990 on corrupt tables?

Question

I have a production VLDB that I'm using Paul Randal's guidance on to spread DBCC CHECKDB workload over a week. I'm logging the results of DBCC CHECKTABLE WITH TABLERESULTS and DBCC CHECKALLOC WITH TABLERESULTS to a table an noticed DBCC CHECKTABLE WITH TABLERESULTS was only returning a single row per table on non-corrupt tables. Here's the first few columns.

Error   Level   State   MessageText      
2593    10      1       There are 57 rows in 1 pages for object "SmallTable".

But when I run DBCC CHECKTABLE WITH TABLERESULTS on a corrupt table in a test database, which I corrupted with this method, I get the following:

Error   Level   State   MessageText
8939    16      98      Table error: Object ID 565577053, index ID 1, partition ID 72057594041335808, alloc unit ID 72057594046971904 (type In-row data), page (1:312). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4.
8928    16      1       Object ID 565577053, index ID 1, partition ID 72057594041335808, alloc unit ID 72057594046971904 (type In-row data): Page (1:312) could not be processed.  See other errors for details.
8980    16      1       Table error: Object ID 565577053, index ID 1, partition ID 72057594041335808, alloc unit ID 72057594046971904 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:312) and previous child (0:0), but they were not encountered.
2593    10      1       There are 0 rows in 0 pages for object "tblWhoops".
8990    10      1       CHECKTABLE found 0 allocation errors and 3 consistency errors in table 'tblWhoops' (object ID 565577053).

I'm curious as to why Error 8990 ins't returned in with the non-corrupt table? DBCC CHECALLOC WITH TABLERESULTS and DBCC CHECKDB WITH TABLERESULTS return this row when there aren't any allocation or consistency errors to report.

Bonus question, why doesn't DBCC CHECKCATALOG have a WITH TABLERESULT arguement?

Answer 1

I'm curious as to why Error 8990 ins't returned in with the non-corrupt table?

I wasn't in the developers mind when it was being thought of, but my guess is to reduce some noise. It'd be redundant to give a summary of the table that had no errors. Since the Check* output is already pretty verbose, my guess is to cut down on some of that since there are no errors.

In fact, looking at the messages they are even labeled in a way that makes me believe they only wanted to give the output when an error occurred.

There are 57 rows in 1 pages for object "SmallTable".
CHECKTABLE found 0 allocation errors and 0 consistency errors in table 'SmallTable' (object ID 645293745).

Since the Check* commands are specifically to investigate and report back their findings (in addition to potentially fixing) you could argue for this either way. To really know, we'd have to ask the original developers if they even remember or had a thought about it.

Bonus question, why doesn't DBCC CHECKCATALOG have a WITH TABLERESULT arguement?

Again, no clue. Best guess would be no one specifically asked for the output in that format or after the initial creation, no time was allotted to go back and add it.