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

by

Troubleshooting Guide: SQL Server Error 5213 — Page Could Not Be Moved During Shrink

Why This Error Happens

Error 5213 occurs when SQL Server’s shrink operation attempts to relocate a page toward the beginning of the data file, but another concurrent process (such as an allocation-related transaction, index rebuild, or DML operation) changes the ownership of that page before the move completes. This is typically a concurrency conflict rather than actual corruption, caused by running DBCC SHRINKFILE or DBCC SHRINKDATABASE while heavy transactional activity, auto-growth events, or parallel maintenance jobs are active on the same database. In rare cases, it can also surface due to underlying allocation page inconsistencies that require integrity verification.

Step-by-Step Resolution Guide

Step 1: Halt Conflicting Workloads Before Retrying Shrink

  • Identify and pause scheduled jobs, ETL processes, or index maintenance plans running against the target database.
  • Check sys.dm_exec_requests and sys.dm_tran_active_transactions for long-running or concurrent write transactions.
  • Temporarily disable SQL Agent jobs tied to the database using SQL Server Management Studio (SSMS) or sp_update_job.

Step 2: Re-run the Shrink Operation in Isolation

  • Execute the shrink during a low-activity maintenance window, ideally with single-user or restricted access mode:
  • ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
  • Run the shrink command again:
  • DBCC SHRINKFILE (N'YourDataFile', TARGETSIZE_MB);
  • Revert access mode once completed:
  • ALTER DATABASE [YourDB] SET MULTI_USER;

Step 3: Validate Database Integrity

  • Run a full consistency check to rule out underlying page corruption:
  • DBCC CHECKDB (N'YourDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;
  • Review the output for allocation errors (Msg 8900-series) that might be triggering ownership instability.
  • If corruption is found, follow standard repair procedures (REPAIR_REBUILD before considering REPAIR_ALLOW_DATA_LOSS).

Step 4: Adjust Shrink Strategy for Large Databases

  • For very large tables, avoid shrinking the entire database at once; instead, shrink individual files incrementally:
  • DBCC SHRINKFILE (N'YourDataFile', 10) WITH NOTRUNCATE;
  • Consider rebuilding indexes afterward, since shrink operations fragment indexes heavily:
  • ALTER INDEX ALL ON YourTable REBUILD;

Alternative or Verification Steps

  • Confirm the fix by re-running DBCC SHRINKFILE and checking the SQL Server Error Log and sys.messages for recurrence of Error 5213.
  • If the issue persists under normal low-traffic conditions, capture an Extended Events session filtering on page_allocated and databases_log_file_used_size_changed to pinpoint the exact process causing ownership churn during the shrink window.