What’s the issue?
Corruption has been detected in a SQL Server database, typically surfaced through DBCC CHECKDB errors, 823/824/825 I/O errors, or entries in the suspect_pages table in msdb. Corruption almost always originates below SQL Server – in the storage subsystem, disk controllers, drivers, or memory – rather than in SQL Server itself.
Why is this a problem?
Corrupted pages can cause query failures, incorrect results, or complete loss of access to tables and indexes. Left unaddressed, corruption spreads as affected pages are read and rewritten, and it propagates into backups, shrinking the window in which a clean restore is possible. Some forms of corruption also prevent transaction log backups from succeeding, breaking your recovery chain entirely.
What should you do about this?
Stop and assess before taking action — do not detach the database or restart the service, as this can make recovery harder. Review the CHECKDB output and error log to identify the exact nature and scope of the corruption. The preferred fix is to restore from the most recent clean backup, which is why verified backups and regular CHECKDB runs matter so much.
If no clean backup is available, options include restoring individual pages (page-level restore), rebuilding affected non-clustered indexes, or as a last resort running DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS — which will cause data loss and should never be the first choice. After recovery, work with your storage and infrastructure teams to identify the underlying hardware cause, since corruption almost always recurs if the root cause is not addressed.
Read more…
SQL Server Corruption – How to prevent it and prepare for it.