The Question Nobody Wants to Answer
“When did DBCC CHECKDB last run on that database?”
Silence.
Nobody knows.
This is not a hypothetical. Corruption can sit undetected for weeks — especially on databases where CHECKDB has been quietly skipped because it was “too slow” or “already scheduled… somewhere.”
By the time you discover it, your good backups may already be rotated off.
These two queries give you your true exposure.
What This Query Does
Part 1 — Last Known Good DBCC per Database
SQL Server tracks the last clean DBCC CHECKDB completion internally via dbi_dbccLastKnownGood.
This is extracted using DBCC DBINFO WITH TABLERESULTS across all user databases.
The result shows you:
- Which databases have never had CHECKDB run
- Which ones haven’t been checked in days / weeks / months
- Sort by
Days Since Last Checkascending — the worst offenders are at the top
Part 2 — Suspect Pages
msdb.dbo.suspect_pages is the SQL Server corruption log.
Any 823/824 error, bad checksum, or torn page gets written here.
If this table has rows, investigate immediately.
The Event Description column tells you whether the corruption is active or has already been resolved via restore or repair.
DBCC CHECKDB and Corruption Check Script
Loading…
Gareth Winterman