- Error number
- 922
- Severity
- 14 (user-correctable error)
- State
- Not documented by Microsoft (not reproduced here)
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
- Category
- Database State & Recovery
- Last reviewed
- 24 October 2026
On this page
What it means
Error 922 means the database is still running crash recovery (replaying and undoing its transaction log), so it cannot be used yet; it normally clears on its own once recovery finishes.
Every time a database starts, SQL Server runs recovery: it reads the transaction log, redoes committed changes that were not yet in the data files, and undoes transactions that were still open. That happens when the instance starts, when a database is restored WITH RECOVERY, when it is set ONLINE or attached, and after an availability group failover. Until recovery ends, the database is in the RECOVERING state and a session that tries to use it gets 922. The name in quotes is the database that is not ready yet.
922 is a waiting message, not a failure. The real question is how long recovery will take, and that depends mostly on how much log must be processed: a large transaction that was open at shutdown, a long time since the last checkpoint, or a log with very many virtual log files (VLFs) make it slow. The catalogue severity is 14; we did not observe the raised level and state. If recovery fails instead of finishing, the database becomes RECOVERY_PENDING or SUSPECT and you get different errors, such as error 3414.
Common causes
- The instance was just restarted (patching, failover of a failover cluster instance, a crash) and the database is still recovering.
- A large or long-running transaction was open at shutdown, so recovery has a lot of work to undo.
- The transaction log has a very large number of VLFs, which slows the analysis and redo phases.
- A restore WITH RECOVERY, ALTER DATABASE ... SET ONLINE or an attach has just started recovery for this database.
- An application or monitoring tool connects to the database before recovery has finished, for example straight after a restart.
Diagnose it
Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.
Which databases are not online yet?
SELECT name, database_id, state_desc, user_access_desc, recovery_model_desc
FROM sys.databases
WHERE state_desc <> N'ONLINE';RECOVERING means recovery is still running and 922 is expected. RECOVERY_PENDING or SUSPECT means it stopped with a problem: look at the error log, not at 922.
How far along is recovery?
Recovery at startup runs as a system request. The completion estimate is rough, especially in the undo phase.
SELECT r.session_id, DB_NAME(r.database_id) AS database_name, r.command,
r.percent_complete,
r.estimated_completion_time / 60000.0 AS est_minutes_left,
r.total_elapsed_time / 60000.0 AS minutes_elapsed
FROM sys.dm_exec_requests AS r
WHERE r.command LIKE N'DB %';A row with DB STARTUP for the recovering database, with a rising percent_complete. No rows (and the database still recovering) means it is waiting for something else; check the error log.
Read the recovery progress messages in the error log
EXEC sp_readerrorlog 0, 1, N'Recovery of database';
EXEC sp_readerrorlog 0, 1, N'Recovery completed';Messages with the percent complete, an estimate of the remaining seconds and the phase (1 analysis, 2 redo, 3 undo), then "Recovery completed" when it is done. A slow phase 3 points to a large transaction being rolled back.
Count virtual log files once the database is online
SELECT COUNT(*) AS vlf_count,
SUM(vlf_size_mb) AS log_size_mb
FROM sys.dm_db_log_info(DB_ID(N'AppDb'));Thousands of VLFs make recovery slow. A log grown in many small steps is the usual reason; see the fixes.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Wait for recovery to finish and retry the connection
Read-onlyWatch diagnostics 2 and 3. When the database is ONLINE, connections work again. Do not restart the service to "speed it up": recovery starts again from the beginning, and an interrupted undo phase only takes longer.
Add retry logic to applications and jobs
Client or network sideApplications that start before the database is ready should retry with a growing delay instead of failing at once. For SQL Server Agent jobs, set retry attempts on the job step.
Shorten future recovery: keep transactions small and the log tidy
Changes configurationBreak large batch operations into smaller transactions, and if the VLF count is high, regrow the log in a few large steps with a sensible fixed growth size. On SQL Server 2019 and later, Accelerated Database Recovery makes the undo phase almost instant regardless of transaction size.
Caution: Shrinking and regrowing the log, and enabling Accelerated Database Recovery, are changes to a production database: plan them for a maintenance window and keep log backups running. Never delete or detach the log to skip recovery; that can leave the database inconsistent.
-- After recovery, in a maintenance window
ALTER DATABASE AppDb MODIFY FILE (NAME = N'AppDb_log', FILEGROWTH = 1024MB);
-- SQL Server 2019 and later
ALTER DATABASE AppDb SET ACCELERATED_DATABASE_RECOVERY = ON;Examples
Connecting right after an instance restart
Shown as documented, not reproduced here: it needs a database that is still recovering. The level and state were not observed, so no header is shown. Once recovery finishes the same statement works.
USE AppDb;Database 'AppDb' is being recovered. Waiting until recovery is finished.
How to prevent it
Avoid huge single transactions (bulk deletes, index rebuilds on very large tables during busy hours) close to planned restarts, keep the log in a reasonable number of VLFs, and consider Accelerated Database Recovery for databases where long rollbacks are common.
After patching or failover, have monitoring wait for every database to be ONLINE in sys.databases before it raises alerts or restarts applications.
Common questions
Can I stop recovery or skip it?
No safe way exists. Recovery is what makes the database consistent. Restarting the service starts it again from the beginning, and removing the log can leave the database damaged.
How long will recovery take?
It depends on the log that must be processed. The error log prints a percent complete and an estimate of the remaining seconds for each phase; use those rather than guessing.
Recovery finished but the database is RECOVERY_PENDING. Is that the same problem?
No. RECOVERY_PENDING means recovery could not start or complete, often because a file is missing or the disk is full. Read the error log for the underlying error.
Learn more on CodeWithSQL
Official documentation
- Database states (SQL Server)
- Accelerated database recovery
- sys.dm_exec_requests (Transact-SQL)
- Database Engine events and errors 0 to 999
Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.