Tempdb-Probleme — voll, langsam oder Contention

Tempdb ist das Schmiermittel des ganzen Servers. Wenn es klemmt, klemmt alles — so unterscheidest du die drei Krankheitsbilder.

Es ist Montagmittag, 12:05 Uhr. Bei der Musterwerk GmbH bricht der große Monatsreport mit einer Fehlermeldung ab, die erst einmal niemand der Datenbank zuordnet: Could not allocate space for object 'dbo.SORT temporary run storage' in database 'tempdb' because the 'PRIMARY' filegroup is full — Error 1105. Fünf Minuten später meldet sich die Auftragserfassung: gleiche Meldung, völlig andere Anwendung, völlig andere Datenbank. Dann das CRM. Der Verdacht „die Anwendungen sind kaputt“ hält genau so lange, bis jemand auf das Laufwerk T: schaut: 0 Bytes frei, und eine einzige Datei namens tempdb.mdf hat sich über das Wochenende auf 240 GB aufgebläht.

Willkommen bei der Datenbank, die allen gehört und um die sich deshalb niemand kümmert. Tempdb ist das Schmiermittel des gesamten Servers: Jede Sortierung, die nicht in den Speicher passt, jede Temp-Tabelle, jede Zeilenversion landet dort — aus allen Datenbanken der Instanz. Genau deshalb trifft ein tempdb-Problem immer sofort alle, und genau deshalb lohnt es sich, die drei Krankheitsbilder sauber zu unterscheiden: voll, langsam und Contention. Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) zeigt dir für jedes Bild die Diagnose und die Therapie — und warum die drei völlig unterschiedliche Ursachen haben.

Was macht tempdb so besonders?

Tempdb ist die gemeinsame Werkbank der Instanz, und drei Eigenschaften machen sie zum Sonderfall. Erstens: Es gibt genau eine pro Instanz — alle Datenbanken, alle Anwendungen, alle Sessions teilen sie sich. Eine Anwendung, die tempdb flutet, schädigt damit automatisch alle anderen; das ist der Grund, warum die Lead-Szene drei „unabhängige“ Anwendungen gleichzeitig trifft. Zweitens: Tempdb wird bei jedem Dienststart neu erstellt — aus der Modell-Datenbank, mit den konfigurierten Dateigrößen. Was bedeutet: Ein Neustart kaschiert jedes tempdb-Problem für genau einen Lastzyklus, und alle Beweise sind danach vernichtet. Drittens: In tempdb landet erstaunlich viel, von dem Entwickler gar nicht wissen, dass sie es dort ablegen.

Die Bewohnerliste: Benutzerobjekte wie #Temp-Tabellen und Tabellenvariablen. Interne Objekte wie Sortier- und Hash-Zwischenstände — jede Sortierung und jeder Hash-Join, der nicht in seinen Speicher-Grant passt, spillt nach tempdb. Und der Version Store: alte Zeilenversionen für Read Committed Snapshot Isolation, Snapshot Isolation, Trigger und lesbare Always-On-Secondaries. Diese drei Verbraucher haben völlig unterschiedliche Wachstumsmuster — und die erste Diagnose-Frage bei „tempdb voll“ lautet deshalb immer: Wer von den dreien ist es?

Daraus ergeben sich die drei Krankheitsbilder. Voll (Error 1105 für Daten, 9002 für das tempdb-Log): Einer der drei Verbraucher wächst unkontrolliert. Langsam: Das Storage unter tempdb kommt mit der I/O-Last nicht mit — sichtbar als PAGEIOLATCH-Waits auf Datenbank-ID 2. Und Contention: zu viele Sessions allokieren gleichzeitig, und es bildet sich Gedrängel an den internen Verwaltungsseiten — sichtbar als PAGELATCH-Waits (ohne IO!). Die Unterscheidung der beiden Latch-Typen ist so wichtig, dass sie eine eigene Box verdient:

Der Diagnose-Pfad: drei Bilder, drei Wege

Die folgende Skizze zeigt die Architektur — mehrere gleich große Datendateien als gesunde Basis — und darunter die drei Krankheitsbilder mit ihren Erkennungszeichen und der jeweils passenden DMV:

Erste Diagnose: konkrete Skripte

Bild 1 — Voll: Wer belegt den Platz?

Die erste Abfrage beantwortet die Verbraucher-Frage auf Instanz-Ebene — Benutzerobjekte, interne Objekte oder Version Store:

Dominieren die internen Objekte, hast du ein Spill- oder Sortier-Thema — weiter zu Ursache zwei. Dominiert der Version Store, suchst du eine lange offene Transaktion — Ursache eins. Dominieren die Benutzerobjekte, zeigt dir die Session-Abfrage, welche Anwendung gerade Temp-Tabellen-Schlachten schlägt. Damit ist die Richtung in zwei Minuten klar — deutlich besser, als auf das volle Laufwerk zu starren.

Bild 3 — Contention: das Gedrängel live sehen

Für Bild 2 — langsam brauchst du kein neues Skript: Die I/O-Latenz-Abfrage über sys.dm_io_virtual_file_stats aus dem I/O-Beitrag des Notarztwagens, gefiltert auf Datenbank-ID 2, zeigt dir die Antwortzeiten der tempdb-Dateien. Liegen sie über den üblichen Richtwerten, während die anderen Datenbanken auf demselben Storage gesund antworten, erzeugt tempdb schlicht mehr I/O, als geplant war — meist als Folge von Spill-Lawinen, also wieder Ursache zwei. Erst wenn alles auf dem Volume lahmt, ist es ein echtes Storage-Thema.

Die häufigsten Ursachen — und was du dagegen tust

1. Der Version Store wächst — eine Transaktion bremst die Müllabfuhr

Der Version Store hat eine unbarmherzige Regel: Aufgeräumt wird nur, was keine laufende Transaktion mehr braucht. Eine einzige vergessene, seit Stunden offene Transaktion — gern eine schlafende SSMS-Session — friert die Bereinigung ein, und der Store wächst mit jeder Änderung auf dem ganzen Server weiter. Besonders betroffen: Systeme mit RCSI und Always-On-Umgebungen mit lesbaren Secondaries, wo auch Abfragen auf dem Replica die Bereinigung aufhalten können. So findest du den Bremser:

Die Therapie ist dieselbe wie bei Blocking-Kaskaden: Besitzer kontaktieren, committen oder rollbacken lassen — oder nach der KILL-Checkliste aus dem Blocking-Beitrag gezielt eingreifen. Strukturell gilt: kurze Transaktionen sind nicht nur Sperren-Hygiene, sondern auch Version-Store-Hygiene.

2. Spill-Lawinen — Statistiken lügen, tempdb zahlt

Jede Sortierung und jeder Hash-Join bekommt vor dem Start einen Speicher-Grant — bemessen nach der geschätzten Zeilenzahl. Liegen die Statistiken daneben, ist der Grant zu klein, und die Operation spillt nach tempdb: aus einer Speicher-Operation wird eine Plattenoperation, sichtbar als HASH_WARNING und SORT_WARNING bzw. als Warndreieck im Ausführungsplan. Einzelne Spills sind Alltag; ein Report, der millionenfach spillt, kann tempdb im Alleingang fluten und nebenbei das Storage in die Knie zwingen. Therapie: Statistiken der beteiligten Tabellen aktualisieren, Kardinalitätsprobleme der Query beheben (Stichwort Parameter Sniffing — eigener Beitrag), und bei chronischen Kandidaten den Query Store zur Beobachtung einspannen.

3. Temp-Table-Schlachten — die Anwendung als Flutwelle

Manche Anwendungen — gern ORM-generierter Code oder Reporting-Schichten — legen pro Bildschirmaufbau dutzende Temp-Tabellen an, kopieren halbe Tabellen hinein und werfen sie wieder weg. Tempdb wird damit zur Durchlauferhitzer-Datenbank: Die Session-Abfrage aus dem Diagnose-Abschnitt entlarvt die Täter über program_name und Allokationsvolumen. Kurzfristig hilft nur Kapazität; mittelfristig gehört der Befund auf den Tisch des Herstellers — mit den Zahlen aus der DMV als Beweismittel. Und ja: Dieselbe Allokations-Frequenz ist auch der Brandbeschleuniger für Krankheitsbild drei.

4. PAGELATCH-Contention — Gedrängel an den Verwaltungsseiten

Jede Allokation in tempdb muss interne Verwaltungsseiten anfassen — PFS, GAM, SGAM —, und die kann immer nur eine Session zur Zeit ändern. Bei hoher Allokations-Frequenz (viele kleine Temp-Tabellen, viele parallele Sessions) bildet sich dort eine Warteschlange: PAGELATCH_UP und PAGELATCH_EX auf den berüchtigten Adressen 2:1:1 und Verwandten. Die Therapie ist seit Jahren dieselbe und wirkt zuverlässig: mehrere gleich große Datendateien (Faustregel: eine pro Kern bis acht), damit sich die Allokationen auf mehrere PFS/GAM/SGAM-Ketten verteilen — plus ab SQL Server 2019 die Memory-Optimized tempdb Metadata gegen das Gedrängel an den Systemtabellen. Beides im Detail, inklusive der Stolperfallen: der Konfigurations-Beitrag der GRÜN-Stufe.

5. Die Autogrow-Falle — klein geboren, in Trippelschritten gewachsen

Der unspektakulärste, aber häufigste Konfigurationsfehler: tempdb startet mit den historischen Mini-Defaults, und das echte Arbeitsvolumen wird über hunderte kleine Autogrow-Schritte zusammengestottert — jeder einzelne eine kleine Vollbremsung, bei der obendrein die Dateigrößen auseinanderlaufen können. Und weil tempdb beim Dienststart auf die konfigurierte Größe zurückgesetzt wird, beginnt das Spiel nach jedem Neustart von vorn. Therapie: die im Betrieb gemessene Spitzennutzung als feste Vorallokation eintragen, alle Dateien gleich groß, identische Autogrow-Werte als Notfallreserve — und Instant File Initialization aktivieren, damit ein Wachstum, wenn es doch passiert, nicht zur Gedenkminute wird.

Was du auf keinen Fall tun solltest

Nachsorge: Damit es nicht wiederkommt

Drei strukturelle Maßnahmen nach dem akuten Fall: Erstens, die Konfiguration auf den Stand der Technik bringen — Dateianzahl, gleiche Größen, feste Vorallokation, dediziertes schnelles Volume, ab SQL 2019 Memory-Optimized Metadata. Die komplette Anleitung mit allen Kommandos liefert der Beitrag „Tempdb optimal konfigurieren“ der GRÜN-Stufe — er ist die natürliche Fortsetzung dieses Notfall-Beitrags. Zweitens, Belegungs-Monitoring: Die Verbraucher-Abfrage aus diesem Beitrag regelmäßig wegschreiben, mit Alarm auf Version-Store-Wachstum — dann erkennst du die vergessene Transaktion nach Minuten statt nach 240 GB. Drittens, Statistik-Hygiene ernst nehmen: Gepflegte Statistiken bedeuten passende Speicher-Grants, und passende Grants bedeuten weniger Spills — tempdb-Entlastung als Nebenwirkung guter Wartung.

Vertiefung in der Buchreihe

Tempdb-Interna, Latch-Architektur und der Version Store füllen in der Buchreihe „SQL Server in der Praxis“ eigene Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Notfälle im Notarztwagen

Tempdb hängt mit halben Server zusammen — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege, wenn tempdb jetzt gerade klemmt

Festpreis-Analyse

Tempdb läuft immer wieder voll, keiner weiß, wer es war, und die Konfiguration stammt noch vom Setup-Assistenten? Dafür gibt es die Festpreis-Analyse: Ich prüfe Datei-Layout und Dimensionierung, werte die Verbraucher-Struktur und die Latch-Situation aus, identifiziere Spill-Kandidaten und Version-Store-Bremser und liefere einen Bericht mit priorisierten Maßnahmen — von der Sofort-Konfiguration bis zu den Anwendungs-Befunden für das Herstellergespräch. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn tempdb gerade jetzt vollläuft und reihenweise Anwendungen abbrechen: anrufen. Halte die Ausgabe der Verbraucher-Abfrage aus diesem Beitrag bereit (oder einen Zugang mit VIEW-SERVER-STATE-Rechten) und die Information, was heute anders läuft — Monatsabschluss, neuer Report, Release. Mit der Verbraucher-Verteilung ist die Richtung in Minuten klar, und meist lässt sich der akute Druck ohne Neustart abbauen.

Selbst-Diagnose-Kit

Du willst tempdb selbst in den Griff bekommen? Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — Verbraucher-Analyse, Session-Top-Liste, Contention-Check mit Seiten-Einordnung, Version-Store-Bremser — als ausführbares Paket mit Auswertungshilfe und einer Konfigurations-Checkliste nach aktuellem Stand der Technik.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Wie viele tempdb-Dateien brauche ich?

Die bewährte Faustregel: eine Datendatei pro logischem Prozessorkern, bis maximal acht — bei mehr als acht Kernen startest du mit acht und erhöhst nur, wenn weiterhin PAGELATCH-Contention messbar ist, dann in Vierer-Schritten. Mindestens so wichtig wie die Anzahl: Alle Dateien müssen gleich groß sein und identische Autogrow-Einstellungen haben, sonst konzentriert der proportionale Füllalgorithmus die Last wieder auf die größte Datei und die schöne Verteilung ist dahin. Seit SQL Server 2016 legt übrigens schon das Setup mehrere Dateien an. Die Details stehen im Konfigurations-Beitrag (/sql-server-tempdb-konfigurieren/).

Was bedeutet tempdb-Contention?

Contention heißt Gedrängel: Viele Sessions wollen gleichzeitig Platz in tempdb allokieren — etwa weil die Anwendung pausenlos Temp-Tabellen anlegt — und müssen dafür dieselben internen Verwaltungsseiten (PFS, GAM, SGAM) anfassen. Diese Seiten kann immer nur einer zur Zeit ändern, also bilden sich Warteschlangen, sichtbar als PAGELATCH_UP- und PAGELATCH_EX-Wartezeiten. Wichtig: Das ist kein Storage-Problem, sondern ein Speicher-internes Gedrängel — schnellere Platten helfen exakt gar nicht. Die Therapie sind mehrere gleich große Datendateien und seit SQL 2019 die Memory-Optimized tempdb Metadata.

Wie diagnostiziere ich tempdb-Latch-Contention?

Live über sys.dm_os_waiting_tasks: Filtere auf Wartetypen wie PAGELATCH_UP und PAGELATCH_EX und schau in die resource_description. Steht dort etwas wie 2:1:1, 2:1:2 oder 2:1:3, warten die Sessions auf die Verwaltungsseiten der tempdb (Datenbank-ID 2) — die Ziffernfolge ist Datenbank:Datei:Seite, und Seite 1 ist die PFS-, Seite 2 die GAM-, Seite 3 die SGAM-Seite. Wiederholt sich dieses Muster unter Last, hast du klassische Allokations-Contention. Das fertige Diagnose-Skript samt Einordnung der Seitennummern findest du im Diagnose-Abschnitt dieses Beitrags.

Was bedeutet HASH_WARNING und SORT_WARNING?

Beides sind Spill-Warnungen: Eine Query hat für ihre Hash-Operation bzw. Sortierung weniger Arbeitsspeicher bekommen, als sie tatsächlich brauchte — und musste auf tempdb ausweichen. Aus einer Speicher-Operation wird damit eine Festplatten-Operation: deutlich langsamer für die Query selbst und zusätzliche Schreiblast für tempdb. Vereinzelt ist das harmlos; massenhaft deutet es auf veraltete Statistiken oder schiefe Kardinalitätsschätzungen hin, denn die Speicherzuteilung basiert auf der geschätzten Zeilenzahl. Spills erkennst du im Ausführungsplan am Warndreieck und systematisch über Extended Events oder den Query Store.

Was ist der Version Store?

Der Version Store ist der Bereich in tempdb, in dem SQL Server alte Zeilenversionen aufbewahrt — gebraucht von Read Committed Snapshot Isolation, Snapshot Isolation, Triggern und lesbaren Always-On-Secondaries. Der Haken: Der Store kann erst aufräumen, wenn keine laufende Transaktion die alten Versionen mehr braucht. Eine einzige vergessene, stundenlang offene Transaktion blockiert also die Bereinigung — und der Version Store wächst, bis tempdb voll ist. Mit sys.dm_tran_active_snapshot_database_transactions findest du die Bremser; das Skript dazu steht im Ursachen-Abschnitt dieses Beitrags.

Wie groß sollte ich tempdb dimensionieren?

Es gibt keine Formel, aber eine belastbare Methode: tempdb so groß vorallokieren, dass der normale Betrieb inklusive der bekannten Lastspitzen (Monatsabschluss, Index-Rebuilds, große Reports) ohne Autogrow auskommt. Als Startwert für neue Systeme haben sich grob 10 Prozent der Gesamtdatenmenge etabliert — danach misst du die tatsächliche Spitzennutzung über sys.dm_db_file_space_usage und passt an. Wichtiger als die absolute Zahl: feste Vorallokation statt Autogrow-Stottern, alle Dateien gleich groß, und genug Reserve auf dem Volume. Die komplette Dimensionierungs-Methodik steht im Konfigurations-Beitrag der GRÜN-Stufe.

Welche Trace Flags helfen bei tempdb?

Die berühmten Trace Flags 1117 (alle Dateien einer Filegroup wachsen gemeinsam) und 1118 (volle Extents statt gemischter Allokation) waren bis SQL Server 2014 das Standardrezept gegen Contention. Seit SQL Server 2016 brauchst du sie nicht mehr: Beide Verhaltensweisen sind für tempdb fest eingebaut. Wenn dir eine alte Checkliste diese Flags empfiehlt, ist sie schlicht veraltet. Auf aktuellen Versionen ist die wirksamere Stellschraube die Memory-Optimized tempdb Metadata (ab SQL 2019), die Metadaten-Contention an den Systemtabellen eliminiert — Details und das Aktivierungs-Kommando im Konfigurations-Beitrag.