CHECKDB WITH NO_INFOMSGS

When running DBCC CHECKDB, you will often times get screens of information back stating that the database is all okay, and that it checked every table. This can be quite tedious when you are trying to search through thousands of lines of output to see where the real error is.

You can use the WITH NO_INFOMSGS when running checkdb to have it turn off all the messages that are not directly related to an error in the checkdb output. When using the NO_INFOMSGS option it displays just the problem areas, not the thousands of lines without problems.

Typically when I am trying to look at corruption in SQL Server I run WITH NO_INFOMSGS to focus right in on the problem.

Msg 8938, Level 16, State 2, Line 7
Table error: Page (1:1849), Object ID 2073058421, index ID 2, partition ID 72057594038386688, alloc unit ID 72057594043367424 (type In-row data). Unexpected page type 1.
Msg 8976, Level 16, State 1, Line 7
Table error: Object ID 2073058421, index ID 2, partition ID 72057594038386688, alloc unit ID 72057594043367424 (type In-row data). Page (1:1849) was not seen in the scan although its parent (1:1832) and previous (1:1848) refer to it. Check any previous errors.
Msg 8978, Level 16, State 1, Line 7
Table error: Object ID 2073058421, index ID 2, partition ID 72057594038386688, alloc unit ID 72057594043367424 (type In-row data). Page (1:1850) is missing a reference from previous page (1:1849). Possible chain linkage problem.
CHECKDB found 0 allocation errors and 3 consistency errors in table ‘Customers’ (object ID 2073058421).
CHECKDB found 0 allocation errors and 3 consistency errors in database ‘CorruptionChallenge6_copy’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (CorruptionChallenge6_copy).

Just part of the Stedman Solutions, LLC regular process of repairing corrupt databases.

CHECKDB WITH NO_INFOMSGS

Leave a Reply Cancel reply

Login