Troubleshooting Guide: SQL Server Error 824 – Logical Consistency-Based I/O Error
Why This Error Happens
Error 824 occurs when SQL Server reads a page from disk and detects that the data does not match what it expects, indicating a logical consistency failure such as a torn page, checksum mismatch, or bad page ID. This is typically caused by underlying storage subsystem corruption, faulty disk controllers, SAN/NAS firmware bugs, or memory/driver issues that silently corrupt data between the OS and the physical disk. In virtualized environments (Hyper-V on Windows Server 2025), it can also stem from misconfigured storage filters, antivirus scanning database files, or improper VM snapshot handling of VHDX files.
Step-by-Step Resolution Guide
Step 1: Identify the Scope of Corruption
- Open the SQL Server Error Log via SSMS or
%ProgramFiles%\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOGand locate the full 824 message, noting the database ID, file name, and page ID. - Run
DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGSto get a complete list of affected objects and corruption severity. - Cross-reference the page offset reported in the error with
DBCC PAGEto determine if it’s a data, index, or system page.
Step 2: Check the Underlying Storage Hardware
- Open Windows Event Viewer (
eventvwr.msc) and inspect the System log for Disk, ntfs, or storahci warnings/errors around the same timestamp as the SQL error. - Run
chkdsk X: /f /ron the volume hosting the .mdf/.ldf files (requires a reboot if it’s the OS/data drive) to scan for physical disk inconsistencies. - If running on a SAN or Storage Spaces Direct (S2D) cluster, check the storage vendor’s diagnostic tool or
Get-PhysicalDisk | Get-StorageReliabilityCounterin PowerShell for predictive failure indicators. - Verify firmware and driver versions for the HBA/RAID controller are current via Windows Update or OEM support site.
Step 3: Exclude SQL Server Files from Antivirus and Backup Agents
- Navigate to Windows Security > Virus & threat protection > Manage settings > Add or remove exclusions.
- Add exclusions for the full SQL Server data directory (e.g.,
D:\SQLData\), log directory (e.g.,L:\SQLLogs\), and TempDB path. - Ensure third-party backup software (e.g., VEEAM, Commvault) is configured to use SQL Server VSS writer correctly and does not lock or scan live .mdf/.ndf/.ldf files during snapshots.
Step 4: Restore or Repair the Affected Database
- If a clean, recent backup exists, restore the database using
RESTORE DATABASE YourDB FROM DISK = 'E:\Backups\YourDB.bak' WITH REPLACE. - If no backup is available, run
DBCC CHECKDB ('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS)as a last resort, understanding this may delete corrupted rows to restore logical consistency. - Always run the repair in
SINGLE_USERmode first:ALTER DATABASE YourDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE.
Step 5: Enable Proactive Monitoring to Prevent Recurrence
- Enable Page Verify CHECKSUM on the database:
ALTER DATABASE YourDB SET PAGE_VERIFY CHECKSUM. - Schedule a recurring SQL Agent job to run
DBCC CHECKDBweekly during low-traffic windows. - Configure Windows Server 2025’s Storage Health Monitoring (via Windows Admin Center) to send alerts on disk-level failures proactively.
Alternative or Verification Steps
- After remediation, re-run
DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGSand confirm it returns 0 allocation errors and 0 consistency errors. - If corruption recurs on the same LUN/volume after hardware checks pass, consider migrating the database files to a different physical disk or storage array to rule out a persistent hardware fault.