Back to All Scenarios
PASSEDdatabase / sql_server_tempdb_full
SQL Server TempDB Full — All Queries Blocked
SQL Server TempDB runs out of space due to a runaway query creating massive temp tables and sort operations. All concurrent queries requiring TempDB (sorts, hash joins, temp tables, version store) are blocked. The entire instance becomes effectively frozen.
Pattern
DATABASE_EVENT
Severity
CRITICAL
Confidence
95%
Remediation
Auto-Heal
Test Results
| Metric | Expected | Actual | Result |
|---|---|---|---|
| Pattern Recognition | DATABASE_EVENT | DATABASE_EVENT | |
| Severity Assessment | CRITICAL | CRITICAL | |
| Incident Correlation | Yes | 42 linked | |
| Cascade Escalation | Yes | Yes | |
| Remediation | — | Auto-Heal — Corax resolves autonomously |
Scenario Conditions
SQL Server 2022 Standard. TempDB on a dedicated 100GB volume. Runaway query consuming 95GB in TempDB. 400 concurrent sessions. All queries requiring sort/hash/temp operations blocked. Version store cleanup unable to reclaim space.
Injected Error Messages (3)
SQL Server TempDB full — error 1105: could not allocate space for object in database 'tempdb', TempDB size: 99.7GB/100GB, runaway session SPID 312 consuming 95GB in sort operations, sys.dm_db_file_space_usage: version_store_reserved_page_count growing, all sessions requiring temp space are blocked, database connection pool backing up
ERP application queries failing — SqlException: 'Could not allocate a new page for database tempdb due to insufficient disk space', all report generation halted, transaction processing blocked on sort operations, 400 users experiencing frozen screens, max connections reached on application server
SSRS report rendering completely blocked — all scheduled and on-demand reports failing with TempDB allocation error, subscription delivery queue depth: 847 reports pending, executive dashboard returning blank, slow query backlog causing cascading failures across reporting infrastructure
Neural Engine Root Cause Analysis
SQL Server's TempDB database has reached its maximum allocated size (99.7GB/100GB) and cannot allocate additional space for operations. A runaway session (SPID 312) is consuming 95GB through excessive sort operations, likely due to an inefficient query or process running without proper optimization. The version store is also growing, indicating potential long-running transactions or snapshot isolation issues, causing all other sessions requiring temporary space to be blocked and creating a cascade effect across dependent systems.
Remediation Plan
1. Immediately kill the runaway session SPID 312 to free up TempDB space. 2. Identify and terminate any other long-running transactions contributing to version store growth. 3. Shrink TempDB files if possible after space is freed. 4. Monitor TempDB usage and investigate the root query/process that caused the runaway session. 5. Consider increasing TempDB size allocation or optimizing the problematic queries to prevent recurrence.
Tested: 2026-03-30Monitors: 3 | Incidents: 3Test ID: cmncjtcsc04ioobqexlq3lpsn