Wenn TempDB aus allen Nähten platzt

Du hast’s sicher schon erlebt:
Plötzlich ist auf C:\ kein Platz mehr.
SQL Server meldet Fehler beim Sortieren oder Joinen.

Und schuld ist: TempDB.
Unbegrenzt gewachsen.
Unkontrolliert benutzt.

TempDB ist die Werkbank von SQL Server – aber wenn keiner aufräumt, wird’s unbrauchbar.

TempDB verstehen: Was landet da alles drin?

• Sortierungen, Hash Joins, Worktables
• Cursors, Table Variables, Online-Index-Operationen
• Version Store für Snapshot Isolation / RCSI
• #Temp-Tabellen
• Rebuilds von großen Indizes
• Abfragen mit ORDER BY OFFSET FETCH

Kurz: alles, was der Optimizer intern braucht – und Du nicht siehst.

TempDB-Größe prüfen

SELECT 
    name,
    size * 8 / 1024 AS size_MB,
    max_size * 8 / 1024 AS max_size_MB,
    growth * 8 / 1024 AS growth_MB,
    physical_name
FROM sys.master_files
WHERE database_id = 2;

Wichtig:

• alle Dateien ungefähr gleich groß
• Autogrowth in MB, nicht Prozent
• sinnvolles MaxSize setzen (z. B. 10–20 GB pro Datei)

Best Practice: Datei-Konfiguration

Einstellung	Empfehlung
Anzahl Dateien	1 pro logischem CPU-Kern (max. 8 bei <128)
Größe	identisch pro Datei
Autogrowth	fester Wert (z. B. 256 MB)
Ort	eigene SSD (nicht auf C:)
Traceflag 1117 / 1118	ab SQL 2016 automatisch enthalten

TempDB-Dateien anlegen:

USE [master];
GO
ALTER DATABASE [tempdb] MODIFY FILE (NAME = N'tempdev', SIZE = 4GB, FILEGROWTH = 256MB);
GO
ALTER DATABASE [tempdb] ADD FILE (NAME = N'tempdev2', FILENAME = 'D:\SQLDATA\tempdb2.ndf', SIZE = 4GB, FILEGROWTH = 256MB);
-- ... bis gewünschte Anzahl erreicht ist

TempDB-Monitoring: Was füllt das Ding?

SELECT 
    session_id,
    task_allocations.user_objects_alloc_page_count AS user_pages,
    task_allocations.internal_objects_alloc_page_count AS internal_pages,
    task_allocations.version_store_alloc_page_count AS version_pages,
    t.text
FROM sys.dm_db_session_space_usage task_allocations
JOIN sys.dm_exec_requests r ON task_allocations.session_id = r.session_id
JOIN sys.dm_exec_sql_text(r.sql_handle) AS t ON 1 = 1
WHERE task_allocations.internal_objects_alloc_page_count > 1000
ORDER BY internal_pages DESC;

So siehst Du:

• welche Abfrage wie viel Speicher belegt
• was auf Version Store zurückzuführen ist

Version Store prüfen

Wenn RCSI oder Snapshot Isolation aktiv ist:

SELECT 
    transaction_id,
    elapsed_time_seconds,
    is_snapshot,
    session_id
FROM sys.dm_tran_active_snapshot_database_transactions;

Und:

SELECT 
    SUM(version_store_reserved_page_count) * 8 / 1024 AS version_store_MB
FROM sys.dm_db_file_space_usage;

Wenn Du große Werte hast: Check Isolation Levels oder lange laufende Abfragen.

Weitere Tipps

• DBCC FREEPROCCACHE leert nicht die TempDB
• Neustart hilft – aber ist keine Lösung
• Große tempdb-Objekte = große Query-Probleme

Tabelle mit häufigen Ursachen:

Ursache	Maßnahme
schlechte Pläne mit Hash Joins	Statistiken prüfen, Indizes setzen
temp tables ohne DROP	Code bereinigen, Scope prüfen
hohe Sortierlast	ORDER BY prüfen, Paging überdenken
RCSI aktiv mit langen TX	SNAPSHOT vermeiden, ggf. zurückbauen

Mein Fazit

TempDB ist wie ein Container – praktisch, aber wenn er überläuft, gibt’s Chaos.
Du brauchst saubere Größen, klare Grenzen, Monitoring und Awareness.

Wenn Du willst, analysier ich Deine TempDB-Last.
Und setz Dir eine Konfiguration auf, die auch Montagmorgen 9 Uhr durchhält.