Error 3967: Insufficient Space in tempdb to Hold Row Versions

Fix it now

tempdb filled with row versions and your transaction was chosen as the one to sacrifice. The version store holds previous images of rows so that readers under row versioning see a consistent picture without blocking writers, and cleanup cannot pass the oldest transaction that might still need them. One forgotten transaction fills a large tempdb with everybody else’s versions.

USE tempdb;
SELECT SUM(version_store_reserved_page_count)   * 8 / 1024 AS version_mb,
       SUM(user_object_reserved_page_count)     * 8 / 1024 AS user_mb,
       SUM(internal_object_reserved_page_count) * 8 / 1024 AS internal_mb
FROM   sys.dm_db_file_space_usage;

SELECT session_id, transaction_id, transaction_sequence_num, elapsed_time_seconds
FROM   sys.dm_tran_active_snapshot_database_transactions
ORDER BY elapsed_time_seconds DESC;

1. If the version figure dominates, this is your problem. If internal objects dominate instead, you are looking at sorts and hashes spilling out of memory, which is a query tuning problem and a different article.
2. Take the top session from the second query and see what it is doing: SELECT session_id, status, command, last_request_start_time FROM sys.dm_exec_requests WHERE session_id = <spid>;
3. End it if it is abandoned, or let it finish if it is genuine work. Cleanup resumes once the oldest transaction is gone.
4. Confirm which versioning options are on: SELECT name, snapshot_isolation_state_desc, is_read_committed_snapshot_on FROM sys.databases;
5. Give tempdb room: pre-size its files on a volume of their own, with fixed growth increments rather than percentages.

internal_object_reserved_page_count is only meaningful in tempdb, because internal objects exist nowhere else. Run the first query in the tempdb context or the numbers will not mean what you think.

If the version store is falling and the workload is running, you are done. If it fills again tomorrow, the next section explains why cleanup stalls.

Why it happens

When row versioning is in use, updating or deleting a row copies its previous image into the version store in tempdb and leaves a pointer behind. A reader that started earlier follows the chain back to the version it is entitled to see. That is what allows readers not to block writers, and it is the mechanism behind both read committed snapshot isolation and explicit snapshot isolation. Microsoft also lists the other features that generate versions in the same store: online index operations, multiple active result sets, and AFTER triggers.

A background task removes versions that no transaction can still need, and it works out that boundary from the oldest active transaction. A single long-running one therefore holds the whole store open. The store then grows at the rate of your write workload, not at the rate of anything the long transaction is doing, which is why an idle session with an open transaction can fill tempdb overnight while appearing to do nothing at all.

The related codes are not all about capacity, and that is worth being precise about. 3959 is the version store reporting itself full and warning that a transaction needing it may be rolled back. 3958 is a reader that went looking for a versioned row and did not find it. 3966 is a transaction being rolled back because it was marked as a victim earlier, when the version store was shrunk. 3964 is different in kind: it means a DDL statement was issued inside a snapshot isolation transaction, which is not allowed. It has nothing to do with tempdb capacity and it will not be fixed by adding space.

Full reference

What is actually filling tempdb

The five codes, and which are about space

What generates versions besides your isolation level

• Data modifications in a database using read committed snapshot isolation or snapshot isolation.
• Online index operations, which version rows while the index is being built.
• Multiple active result sets, which needs versions to keep interleaved result sets consistent.
• AFTER triggers, which read the previous image of the modified rows.
• So a database with no snapshot isolation at all can still put pressure on the version store, and the first three of those are easy to overlook when the isolation level looks innocent.

Accelerated Database Recovery, and where its versions live

Accelerated Database Recovery is available from SQL Server 2019 and is off by default. When it is enabled on a user database, its persistent version store lives on the PRIMARY filegroup of that database rather than in tempdb, which takes that database’s versioning pressure off tempdb entirely and puts it on the user database’s own files instead. That is a trade rather than a saving, and it needs to be planned for in the data file sizing.

In SQL Server 2025 there is a further wrinkle worth knowing before you size anything. When Accelerated Database Recovery is enabled in tempdb itself, tempdb holds two independent version stores: the traditional one, used for versions generated by user databases that do not have ADR enabled, and a persistent version store used for versions generated by transactions in tempdb. Microsoft’s guidance is to allocate enough space in the tempdb data files for both.

Sizing tempdb from measurement

1. Watch the version store size across a full business cycle, not a quiet afternoon, using the Transactions performance counters and the file space usage query above.
2. Take the maximum you observe and adjust it for the concurrency you expect, then set the file sizes to that.
3. Give every data file the same initial size and growth settings, because the proportional-fill algorithm favours the file with the most free space.
4. Use fixed increments in megabytes, never percentages.
5. Remember that tempdb is recreated from those settings at every start, so configure the size you want rather than growing into it each day.
6. If ADR is enabled in tempdb on SQL Server 2025, size for both version stores.

Every code this article covers

Confirm the fix worked

1. Re-run the tempdb usage query and confirm the version store figure is falling.
2. Confirm no session in sys.dm_tran_active_snapshot_database_transactions has an unreasonable elapsed_time_seconds.
3. Check the error log for further 3967 or 3959 entries after the change.
4. Confirm tempdb’s files are at the sizes you configured after the next instance restart, and that they are all equal.
5. Watch the version store across a full business cycle before concluding it is sized correctly.

Questions people ask about this