SQL Server Error 8921

Error number

8921

Severity

16 (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

Corruption & Consistency

Last reviewed

24 October 2026

What it means

Error 8921 means DBCC CHECKDB (or CHECKTABLE, CHECKFILEGROUP) gave up before checking anything, because it could not collect the information it needs, most often for lack of tempdb space or because of damaged system tables.

DBCC consistency checks work in two stages: first they read the database and store "facts" about every page and row in a worktable in tempdb, then they compare those facts. 8921 is raised in the first stage, so the check did not finish and tells you nothing yet about the user data. The message itself gives the two usual reasons, and "Check previous errors" is the key instruction: the error printed just before 8921 is the real cause.

If the earlier error is about space in tempdb (for example error 1105 naming tempdb), the check simply needs more tempdb than was available, which is common for very large databases or when other workloads fill tempdb at the same time. If the earlier errors are about system tables or metadata, the database itself may be damaged and should be treated like other consistency errors. The catalogue severity is 16; Microsoft does not document the state.

Common causes

• tempdb ran out of space during the check: its files hit their maximum size or the drive is full.
• Other workloads (sorts, hash joins, version store, temporary tables) were using most of tempdb while CHECKDB ran.
• The database is very large and the check was run without estimating the tempdb space it needs.
• A system table (metadata) is inconsistent, so the check cannot build its picture of the database; earlier errors then name system objects.
• Storage problems that make pages unreadable during the fact-collection stage (look for 823 or 824 errors before 8921).

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.

DBCC CHECKDB (N'AppDb') WITH ESTIMATEONLY;

SELECT SUM(unallocated_extent_page_count) / 128 AS free_mb,
       SUM(version_store_reserved_page_count) / 128 AS version_store_mb,
       SUM(internal_object_reserved_page_count) / 128 AS internal_objects_mb,
       SUM(user_object_reserved_page_count) / 128 AS user_objects_mb
FROM tempdb.sys.dm_db_file_space_usage;

SELECT f.name, f.type_desc, f.size / 128 AS size_mb,
       CASE f.max_size WHEN -1 THEN NULL ELSE f.max_size / 128 END AS max_size_mb,
       f.growth, f.is_percent_growth,
       vs.available_bytes / 1048576 AS drive_free_mb
FROM tempdb.sys.database_files AS f
CROSS APPLY sys.dm_os_volume_stats(2, f.file_id) AS vs;

EXEC sp_readerrorlog 0, 1, N'DBCC CHECKDB';
EXEC sp_readerrorlog 0, 1, N'tempdb';

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.

DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS;

ALTER DATABASE tempdb
MODIFY FILE (NAME = N'tempdev', SIZE = 20480MB, FILEGROWTH = 1024MB);

DBCC CHECKTABLE (N'dbo.Orders') WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- Lighter check (physical structure only)
DBCC CHECKDB (N'AppDb') WITH PHYSICAL_ONLY, NO_INFOMSGS;

RESTORE DATABASE AppDb_Check
FROM DISK = N'D:\Backups\AppDb_full.bak'
WITH MOVE N'AppDb'     TO N'D:\SQLData\AppDb_Check.mdf',
     MOVE N'AppDb_log' TO N'D:\SQLLogs\AppDb_Check_log.ldf',
     CHECKSUM;

Examples

CHECKDB on a large database while tempdb is nearly full

Shown as documented, not reproduced here. Earlier errors in the same output (for example a tempdb space error) give the actual cause. The state is not documented by Microsoft, so no header is shown.

DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

How to prevent it

Size tempdb for your largest consistency check: run DBCC CHECKDB ... WITH ESTIMATEONLY for the biggest databases now and then, and alert on tempdb free space. Schedule checks away from heavy batch work, or offload them to a server where backups are restored and checked.

Treat a CHECKDB that ended with 8921 as "no result", not as "no errors": make your maintenance job fail visibly so that a missing check is noticed and rerun.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• DBCC CHECKDB (Transact-SQL)
• tempdb database
• DBCC CHECKCATALOG (Transact-SQL)
• Database Engine events and errors 8000 to 8999

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.