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

Troubleshooting Guide: Error 5063 – Database Is in Warm Standby (Read-Only)

Why This Error Happens

This error occurs because the database is currently operating in warm-standby mode, typically as the target of a log-shipping or restore sequence using NORECOVERY or STANDBY options. SQL Server enforces a read-only state on these databases to preserve transactional consistency with the primary database until the log-shipping chain is formally broken. Attempting to execute INSERT, UPDATE, DELETE, or schema-modification statements against this database triggers Error 5063 because the engine blocks all write operations by design.

Step-by-Step Resolution Guide

Step 1: Confirm the Database Role and Recovery State

  • Open SQL Server Management Studio (SSMS) and connect to the instance on Windows Server 2025.
  • Run the following query to check the current state:
  SELECT name, state_desc, is_in_standby 
  FROM sys.databases 
  WHERE name = 'YourDatabaseName';
  • If is_in_standby returns 1, the database is confirmed to be in warm-standby/read-only mode.

Step 2: Determine if This Is Expected Behavior (Log Shipping)

  • Check SQL Server Agent Jobs (under SQL Server Agent > Jobs) for active LSRestore_* jobs tied to log shipping.
  • If log shipping is intentional, do not write to this database — instead, redirect your application’s write operations to the primary server.
  • Update your application’s connection string or web.config / appsettings.json to point to the primary instance rather than the standby replica.

Step 3: Bring the Database Out of Standby (If Failover Is Intended)

  • If you need to permanently stop log shipping and make this database writable, run a final log restore with recovery:
  RESTORE DATABASE YourDatabaseName WITH RECOVERY;
  • This terminates the restore sequence and transitions the database from STANDBY to a fully operational, read-write state.
  • Note: Once recovered, this database can no longer accept subsequent transaction log restores unless log shipping is reconfigured from scratch.

Step 4: Disable or Reconfigure Log Shipping (If No Longer Needed)

  • Navigate to SSMS > Database Properties > Transaction Log Shipping.
  • Uncheck “This is the primary database” or remove the secondary database configuration.
  • Alternatively, run:
  EXEC sp_delete_log_shipping_secondary_database 'YourDatabaseName';

Step 5: Validate Application Behavior Post-Fix

  • Restart the dependent application pool or service on Windows Server 2025 to clear cached connection states.
  • Re-run the failing transaction to confirm the write operation now succeeds.

Alternative or Verification Steps

  • Run SELECT DATABASEPROPERTYEX('YourDatabaseName', 'Updateability'); — it should return READ_WRITE instead of READ_ONLY.
  • If the database must remain in standby for reporting purposes, configure your application to use a read-only routing connection string instead of attempting writes, avoiding Error 5063 entirely.