Troubleshooting Guide: SQL Server Error 5214 – Page Could Not Be Moved During Shrink

Why This Error Happens

Error 5214 occurs when the DBCC SHRINKFILE or SHRINKDATABASE operation attempts to relocate a page toward the beginning of the file, but the page’s allocation type changes (e.g., from in-row data to another page type, or due to concurrent DDL/index rebuild activity) before the move completes. This is typically caused by concurrent transactional activity, parallel maintenance jobs (such as index reorganization or statistics updates), or heavy DML operations running simultaneously with the shrink process. In rare cases, it can also indicate underlying corruption or metadata inconsistency in the page allocation structures (PFS/GAM/SGAM pages).

Step-by-Step Resolution Guide

Step 1: Isolate the Database from Concurrent Operations

• Stop or pause any scheduled maintenance plans, ETL jobs, or index rebuild/reorganize tasks targeting the affected database.
• Check SQL Agent Jobs under SQL Server Agent > Jobs in SSMS to confirm nothing overlaps with the shrink window.
• Run sp_who2 or query sys.dm_exec_requests to identify active sessions writing to the database during shrink.

Step 2: Run CHECKDB to Validate Page Integrity

• Execute the following to rule out corruption as the root cause:

  DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;

• Review the output for allocation errors (Msg 8909, 8928, etc.) that may indicate PFS/GAM page corruption contributing to the shrink failure.
• If corruption is found, restore from a known good backup rather than attempting repair on a production system.

Step 3: Re-run Shrink in a Controlled, Single-User Context

• Set the database to restrict concurrent access before retrying:

  ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
  DBCC SHRINKFILE (YourLogicalFileName, TargetSizeMB);
  ALTER DATABASE YourDatabaseName SET MULTI_USER;

• This eliminates the race condition between page movement and concurrent page-type changes.

Step 4: Apply Latest Cumulative Update

• Confirm you are on the latest SQL Server 2025 Cumulative Update (CU), as shrink-engine race conditions around page type tracking are periodically patched.
• Check current build via:

  SELECT @@VERSION;

• Download and apply the latest CU from the Microsoft Update Catalog if your build is outdated.

Step 5: Rebuild Indexes Before Shrinking (Preventive)

• Run ALTER INDEX ALL ON [TableName] REBUILD; on heavily fragmented tables prior to shrink operations.
• This reduces the volume of page relocations required, lowering the chance of the type-change race condition.

Alternative or Verification Steps

• Verify the fix: Re-run DBCC SHRINKFILE during a maintenance window with no active sessions and confirm it completes without Error 5214 in the SQL Error Log (EXEC xp_readerrorlog 0, 1, N'5214';).
• Alternative approach: If the error persists, avoid shrinking live and instead perform a BACKUP → recreate database with correctly sized files → RESTORE data via SELECT INTO or BCP, which sidesteps the shrink/page-relocation mechanism entirely.