- 01What SQL Server tempdb is used for
- 02SQL Server tempdb files and growth settings
- 03SQL Server tempdb sizing and file layout checks
- 04How to read SQL Server tempdb space usage
- 05How to find sessions using SQL Server tempdb
- 06SQL Server tempdb version store pressure
- 07SQL Server tempdb worktables and query spills
- 08SQL Server tempdb contention and PAGELATCH waits
- 09SQL Server tempdb storage latency and autogrowth risk
- 10What not to change in SQL Server tempdb
- 11When SQL Server tempdb issues need a health audit
sql server hub / tempdb guide
SQL Servertempdb guide
SQL Server uses tempdb for temporary objects, internal worktables, row versions, sorts, spills, and other work that does not belong in a user database.
Use this guide when tempdb growth, contention, version store, spills, slow jobs, or unclear pressure needs a clean technical check before anyone changes settings.
What SQL Server tempdb is used for
SQL Server tempdb is a shared workspace for the whole instance. It holds user-created temporary objects, internal worktables, work files for sorts and hash joins, row-version store data, temp tables, table variables, cursor work, spool work, and other engine activity that does not belong in a user database.
That makes tempdb both configuration and workload. File count, size, growth, and storage path matter, but the pressure usually comes from sessions, queries, isolation choices, jobs, maintenance, spills, or concurrency patterns.
| Layer | What it answers |
|---|---|
| Files and configuration | Whether tempdb has predictable file count, size, paths, and growth behavior. |
| Space usage | Whether pressure is user objects, internal objects, version store, or free-space shortage. |
| Live consumers | Which sessions, tasks, jobs, hosts, or applications are allocating space now. |
| Waits and contention | Whether pressure is showing up as PAGELATCH waits, blocking, or another wait pattern. |
| Storage and growth | Whether tempdb reads, writes, or autogrowth are part of the slow window. |
SQL Server tempdb files and growth settings
Start with the current SQL Server tempdb file layout. Check data files and the log file separately, then review whether data files are equal enough, sized for the workload, and growing in controlled fixed-size increments.
A file-count change should be based on concurrency and contention data, not a generic rule. Growth settings should be boring enough that tempdb expansion does not become part of an incident.
On a new system without measured load, start conservatively with equally sized tempdb data files: often one file per logical processor up to 8 files, then stop and measure. If contention remains, add files in small groups and measure again. On a system with known load, use peak space, file usage, PAGELATCH waits, allocation contention, and storage latency before deciding whether 4, 8, or more files make sense.
SQL Server tempdb file layout
Lists tempdb file type, size, growth setting, max size, and physical path.
Data files should usually be reviewed for equal sizing and sensible growth. For new workloads without measurements, a common starting point is one equally sized data file per logical processor up to 8 files. If contention remains after that, add files in small groups and measure again instead of jumping to one file per core. For known workloads, use contention, file usage, and latency data before adding more files. Percent growth can create unpredictable growth increments as files become large. Physical paths show whether tempdb is on the expected storage. A file layout mismatch is a review input, not an automatic reason to add files.
SQL Server tempdb sizing and file layout checks
SQL Server tempdb sizing should start from observed peak usage, not from a neat rule somebody remembers from another server. Check the busiest reporting, ETL, maintenance, index, and incident windows before deciding the steady-state size.
Once file count is in a sensible range, the next question is whether the configured size and growth behavior match real peaks. Tempdb is recreated on startup, so undersized files can turn a normal restart into a growth event at the worst time.
Put tempdb on fast storage when the workload uses it heavily, ideally separate from busy user database data and log volumes. If tempdb data files are spread across multiple volumes, keep the latency and capacity characteristics comparable so one slower path does not become the new bottleneck.
| Sizing input | How to use it |
|---|---|
| Observed peak space | Size tempdb for real high-water marks plus headroom, not for the quiet snapshot. |
| Growth events | Frequent growth means the starting size or growth increment is too small for the workload. |
| Storage placement | Prefer fast, predictable storage for tempdb, separate from busy database and log volumes where the platform allows it. |
| Storage latency | High read or write stalls can make a correct size still feel slow. |
| Concurrency | Use PAGELATCH and workload data before adding more files. |
| Restart behavior | Tempdb is recreated on startup, so configured sizes must be intentional before restart. |
How to read SQL Server tempdb space usage
Current space usage tells you which bucket is consuming SQL Server tempdb now. User objects, internal objects, version store, free space, and mixed extents point to different next checks.
Free space alone does not mean tempdb is healthy. A system can have free space and still be suffering from allocation contention, spills, bad growth behavior, uneven file use, or slow tempdb storage. Capture this during the pressure window when possible.
Current SQL Server tempdb space usage
Reads tempdb file space split into free space, user objects, internal objects, version store, and mixed extents.
user_objects_mb points toward temp tables, table variables, or explicit tempdb objects. internal_objects_mb points toward worktables, sort/hash work files, and internal engine work. version_store_mb points toward row versioning, snapshot behavior, or long transactions. free_mb is only one part of the picture; waits, latency, and growth history still matter. Uneven file usage can point back to file layout, growth history, or restart behavior.
How to find sessions using SQL Server tempdb
Session and task usage connect SQL Server tempdb consumption to real work. Session totals are useful for active connections, while task-level rows help when one request is currently allocating heavily.
These counters are best read during the problem window. After a request finishes, some task detail may disappear and the useful link back to query text can be lost. Use the output to decide whether the next check is a query plan, SQL Agent job, transaction, or application source.
Session-level tempdb usage
Shows tempdb allocations by session with host, application, login, status, and transaction count.
user_objects_mb points toward temp tables or explicit tempdb object use. internal_objects_mb points toward sort, hash, cursor, or worktable activity. program_name and host_name connect the usage to an application or job runner. Open transactions can keep work alive longer than expected.
Task and request tempdb usage
Shows task-level tempdb usage with active request status, waits, blocker, and running statement.
task_internal_objects_mb is useful during active spill or worktable pressure. running_statement gives the next query or plan to inspect. wait_type and blocking_session_id help separate tempdb use from blocking. If one request dominates, check its plan, memory grant, and recent changes.
SQL Server tempdb version store pressure
Row-versioning features can reduce reader/writer conflicts, but they move work into SQL Server tempdb. Snapshot isolation, read committed snapshot, online operations, and long-running transactions can all make version store space grow.
Version store pressure should be checked by database, then tied back to transaction length, isolation settings, workload timing, and cleanup behavior. A long-running snapshot transaction can delay cleanup even after the query that created the versions has moved on.
SQL Server tempdb version-store usage by database
Shows how much tempdb space version-store records use for each database.
version_store_mb shows which database is contributing version records. Rapid growth points toward row-versioning workload or long transactions. Low values are normal on systems not using much row versioning. If this grows during incidents, check active transactions and isolation choices next.
Long-running snapshot transactions
Shows active snapshot transactions that can keep version-store cleanup from catching up.
elapsed_time_seconds helps find transactions that have been alive long enough to delay cleanup. session_id connects the transaction to a connection that may need application or job context. High version-chain traversal can point toward expensive version-store reads. Use this together with version-store size by database, not as a standalone verdict.
SQL Server tempdb worktables and query spills
SQL Server can use tempdb for worktables and work files when sorts, hash joins, spools, cursors, or other operators need workspace. Execution plans may show this as a spill to tempdb when the operator did not get enough memory. That can be normal, but repeated spills usually need query-plan review.
Do not blame tempdb first. Check memory grants, estimates, statistics, indexes, row counts, and whether one report, ETL step, or maintenance job keeps pushing the same expensive query shape into tempdb. Use the SQL Server indexing guide when a poor access path widens the work, and the SQL Server slow performance guide when tempdb is only one symptom.
Look for sort, hash, spool, exchange, or worktable operators that spill during the slow window.
Check whether estimates are far from actual row counts before changing tempdb files.
Review memory grants, stale statistics, and missing or weak indexes.
Check the job, report, or application workflow that repeats the same tempdb-heavy shape.
SQL Server tempdb contention and PAGELATCH waits
SQL Server tempdb allocation contention often appears as PAGELATCH_UP, PAGELATCH_EX, or related latch waits against tempdb resources. This is different from storage I/O waits. It is latch contention on in-memory allocation pages, often under high temp object churn or concurrent workload pressure.
The fix depends on the pattern. File layout can matter, but so can query behavior, temp table churn, object design, workload timing, and SQL Server version.
Active waits pointing at tempdb
Shows active waiting tasks and requests where the wait resource or database points toward tempdb.
PAGELATCH waits with tempdb resources can point to PFS, SGAM, or other allocation-page contention. wait_duration_ms shows whether the wait is momentary or building up. program_name and host_name help connect waits to a workload source. Check SQL Server version, temp object churn, and current file layout before adding more files. If blockers appear, continue with the blocking guide before changing tempdb.
SQL Server tempdb storage latency and autogrowth risk
SQL Server tempdb pressure can be allocation contention, space pressure, storage latency, or autogrowth at a bad time. File I/O stats help decide whether tempdb reads and writes are waiting on the storage path.
Job timing matters too. Maintenance, reporting, ETL, index work, and large loads can make tempdb look like the problem when the real issue is workload overlap. Correlate growth events, job history, monitoring data, and latency before moving files or changing file count.
SQL Server tempdb file latency
Reads read/write counts, stalls, and average latency for tempdb files.
avg_write_latency_ms matters because tempdb-heavy work can be write-sensitive. High stalls during pressure windows deserve storage and workload timing review. Compare data and log files separately. Latency numbers need context from monitoring, not one isolated snapshot.
SQL Agent job timing
Checks recent SQL Agent job steps when tempdb pressure may align with maintenance, reporting, or ETL work.
run_start_time lets you compare jobs with tempdb growth or wait spikes. run_duration_seconds helps find jobs overlapping the slow period. Long or failed steps may explain sudden tempdb pressure. If a job aligns with the incident, check its query plans, memory grants, and tempdb usage.
What not to change in SQL Server tempdb
SQL Server tempdb changes can require restarts, storage moves, workload timing, and rollback planning. Treat them as production changes, not small cosmetic cleanup.
Do not add too many tempdb files without contention data.
Do not shrink tempdb as routine cleanup.
Do not treat free space as enough to call tempdb healthy.
Do not use percent growth for large tempdb files.
Do not move tempdb or change growth settings without a rollback and restart plan.
Do not enable row-versioning isolation without checking tempdb capacity and version-store growth.
Do not blame tempdb for spills before checking query plans, memory grants, statistics, and indexes.
Do not rebuild indexes or run maintenance during a tempdb pressure incident unless the job is clearly the cause and can be safely stopped.
Do not ignore PAGELATCH waits pointing at tempdb allocation pages.
When SQL Server tempdb issues need a health audit
A health audit makes sense when SQL Server tempdb pressure is real but tied to other production checks: old file settings, weak monitoring, storage concern, blocking, maintenance overlap, row-versioning changes, or repeated slow periods.
Send tempdb file settings, current space usage, version-store output, session and task usage during pressure, waits, file latency, SQL Agent timing, monitoring data, and recent changes.
Next step
If tempdb is tied to backup, job, monitoring, storage, or blocking issues, use the SQL Server health audit page or request the audit above.
Next useful reads: the SQL Server health check guide for full-environment review, the SQL Server waits guide for wait interpretation, the SQL Server blocking guide for lock chains, the SQL Server indexing guide for plan and spill review, the SQL Server monitoring guide for recurring measurements, and the SQL Server sizing guide when tempdb pressure points back to capacity.
