How to fix Error 8946 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: SQL Server Error 8946 – Allocation Page Header Corruption

Why This Error Happens

Error 8946 occurs when SQL Server’s storage engine detects that an allocation page (such as a GAM, SGAM, or PFS page) has invalid header values, meaning the page’s metadata does not match its expected type. This is almost always caused by physical-level data corruption resulting from faulty disk I/O subsystems, improper shutdowns, storage controller firmware bugs, or failing hardware (RAM/disk). It can also surface after a storage migration or SAN replication process that did not complete a full, consistent write cycle.

Step-by-Step Resolution Guide

Step 1: Confirm the Scope of Corruption

  • Run DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS; to get a full damage report.
  • Note the specific Page ID (PGID) and object ID referenced in the error output.
  • Check the SQL Server Error Log and Windows Event Viewer (Application Log) for correlating disk-related Event IDs (e.g., Event ID 153 or 7).

Step 2: Isolate and Verify Hardware/Storage Integrity

  • On Windows Server 2025 or Windows 11, open PowerShell as Administrator and run Get-PhysicalDisk | Get-StorageReliabilityCounter to check for read/write errors on the underlying disk.
  • Run chkdsk C: /f /r (replace with the correct drive letter hosting your .mdf/.ndf files) and schedule a restart if prompted.
  • Verify that Windows Server storage drivers and firmware for the RAID/SAN controller are updated to the latest stable version.

Step 3: Restore From a Clean Backup (Preferred Method)

  • Take a tail-log backup if the database is still accessible: BACKUP LOG YourDatabaseName TO DISK = 'C:\Backups\TailLog.trn' WITH NORECOVERY;
  • Restore the last known good full backup, followed by differential and log backups in sequence:
  • RESTORE DATABASE YourDatabaseName FROM DISK = 'C:\Backups\FullBackup.bak' WITH NORECOVERY;
  • RESTORE LOG YourDatabaseName FROM DISK = 'C:\Backups\TailLog.trn' WITH RECOVERY;
  • This avoids data loss and is the only Microsoft-supported method to resolve allocation-level corruption fully.

Step 4: Run Repair as a Last Resort (If No Backup Exists)

  • Put the database in single-user mode: ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
  • Execute DBCC CHECKDB ('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
  • Be aware this command may deallocate corrupted pages, resulting in permanent data loss for those specific rows/objects.
  • Set the database back to multi-user: ALTER DATABASE YourDatabaseName SET MULTI_USER;

Alternative or Verification Steps

  • After restoring or repairing, re-run DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS; to confirm zero allocation errors are returned.
  • If corruption recurs on the same LUN or volume after repair, treat it as a hardware failure signal and migrate the database files to a different physical disk or storage array immediately.