Tempdb optimal konfigurieren

Wie viele Dateien, wie groß, auf welchem Storage? Die fünf Stellschrauben einer Wegwerf-Datenbank, an der der ganze Server hängt.

Es gibt in jedem SQL Server eine Datenbank, die niemandem gehört und an der trotzdem alle hängen: tempdb. Sie speichert nichts dauerhaft, wird bei jedem Neustart frisch erstellt und ist im Grunde eine große, gemeinschaftlich genutzte Kratzfläche — und genau deshalb wird sie so oft stiefmütterlich behandelt. „Ist doch nur die temporäre Datenbank“, denkt sich mancher, lässt die Standardkonfiguration aus der Installation stehen und wundert sich Jahre später, warum der Server unter Last seltsam zäh wird, obwohl CPU und Speicher Reserven zeigen. Die Wahrheit ist: tempdb ist das Schmiermittel der ganzen Instanz, und ein schlecht konfiguriertes Schmiermittel bremst die ganze Maschine.

Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) zeigt dir, wie du tempdb von Anfang an richtig aufstellst — fünf Stellschrauben, die zusammen darüber entscheiden, ob die gemeinsame Kratzfläche reibungslos läuft oder zum heimlichen Flaschenhals wird. Als Beitrag der GRÜN-Stufe geht es hier um die Konfiguration im Ruhezustand, die Probleme verhindert. Wer tempdb erst im Notfall anfasst — wenn sie volläuft oder unter Contention ächzt —, ist beim akuten tempdb-Beitrag der GELB-Stufe richtig; dieser hier sorgt dafür, dass es so weit gar nicht kommt.

Was tempdb ist — und warum sie alle angeht

Tempdb ist die eine, gemeinsame Arbeitsdatenbank einer SQL-Server-Instanz: Es gibt sie genau einmal, und jede Datenbank der Instanz teilt sie sich. In ihr passiert all das, wofür der Server kurzfristig Platz braucht und der nicht dauerhaft gespeichert werden muss: Sortierungen und Hash-Joins, die nicht in den Arbeitsspeicher passen und nach tempdb auslagern (die berüchtigten Spills), explizite temporäre Tabellen und Tabellenvariablen, der Version Store für Snapshot-Isolation und Online-Operationen, sowie diverse interne Zwischenergebnisse. Tempdb ist, kurz gesagt, der Werktisch, auf dem der Server alles ablegt, was er gerade in den Händen hat.

Aus dieser zentralen Rolle folgt die ganze Wichtigkeit der Konfiguration: Ist der Werktisch zu klein, zu langsam oder schlecht organisiert, trifft das nicht eine Datenbank, sondern alle. Eine zähe tempdb verlangsamt jede Sortierung jeder Abfrage jeder Anwendung auf dem Server gleichzeitig. Und weil tempdb bei jedem Start neu entsteht, ist ihre Konfiguration einer der wenigen Bereiche, in denen du mit ein paar bewussten Entscheidungen einmalig viel richtig machen kannst — ohne Backup-Sorgen, ohne Datenverlust-Risiko, denn es gibt schlicht nichts zu verlieren. Das ist ein angenehmer Sonderfall in der Welt der Datenbank-Konfiguration: Sonst hängt an fast jeder Änderung die bange Frage nach Wiederherstellbarkeit und Konsistenz — bei tempdb darfst du beherzt zugreifen, weil ein misslungener Versuch im schlimmsten Fall einen Neustart kostet und keine einzige Zeile produktiver Daten.

Die häufigste tempdb-Engstelle hat einen Namen: Allokations-Contention. Wenn viele Sessions gleichzeitig temporäre Objekte anlegen, drängeln sie sich um dieselben internen Verwaltungsseiten — PFS, GAM und SGAM —, die den freien Platz in einer Datei verwalten. Auf einer einzigen tempdb-Datei wird diese Verwaltung zum Nadelöhr, sichtbar als PAGELATCH-Wartezeiten (nicht zu verwechseln mit PAGEIOLATCH, dem Platten-Warten). Die elegante Lösung ist verblüffend simpel und der Kern der ganzen tempdb-Konfiguration: mehrere gleich große Dateien, über die sich die Verwaltungs-Last verteilt.

Die fünf Stellschrauben

Eine gute tempdb-Konfiguration besteht aus fünf Entscheidungen, die zusammenwirken. Die folgende Übersicht ist die Konfigurations-Landkarte — von der Dateianzahl bis zum modernen Metadata-Feature:

Die Skripte: prüfen und konfigurieren

Schritt 1 — Den Ist-Zustand prüfen

Bevor du etwas änderst, der Blick auf die aktuelle Aufstellung: Wie viele Dateien gibt es, sind sie gleich groß, wie ist das Autogrow konfiguriert?

Die typischen Funde: nur eine Datendatei (Allokations-Contention vorprogrammiert), Dateien mit ungleicher Größe (Proportional Fill verteilt ungleich), oder ein Autogrow von 10 Prozent (das wird mit wachsender Datei immer gröber und ruckartiger). Stimmt einer dieser Punkte nicht, lohnt die Korrektur.

Schritt 2 — Auf Allokations-Contention prüfen

Zeilen mit PAGELATCH-Waits auf Ressourcen, die mit 2: beginnen (tempdb hat immer die Datenbank-ID 2), sind der direkte Nachweis von Allokations-Contention — die typischen Adressen sind 2:1:1 (PFS), 2:1:2 (GAM) und 2:1:3 (SGAM). Tauchen sie regelmäßig auf, ist die Dateianzahl die erste Stellschraube.

Schritt 3 — Dateien hinzufügen und gleich dimensionieren

Die Konfiguration im Detail

Storage: eigenes, schnelles Volume

Tempdb gehört auf das latenzärmste Storage, das du hast, und idealerweise auf ein eigenes Volume, getrennt von Daten- und Logdateien — denn sie konkurriert sonst um dieselbe I/O-Warteschlange. Ihr Zugriffsmuster (viele kleine, zufällige Lese- und Schreibvorgänge) ist genau das, was Flash und NVMe maximal belohnen. Der große Vorteil gegenüber jeder anderen Datenbank: tempdb muss weder gesichert noch hochverfügbar gehalten werden, weil sie bei jedem Start neu entsteht. Das macht sie zum idealen Kandidaten für schnelles lokales NVMe — sogar in einem Failover-Cluster, wo sie als einzige Datenbank nicht auf gemeinsamem Storage liegen muss. Diese Ausnahme ist ein häufig übersehener Performance-Hebel: Während die Nutzdatenbanken im Cluster zwingend auf dem gemeinsam erreichbaren Storage liegen müssen, damit sie beim Failover auf dem anderen Knoten verfügbar sind, gilt das für tempdb gerade nicht — sie wird auf dem Zielknoten ohnehin neu erstellt. Jeder Cluster-Knoten kann seine eigene tempdb auf schnellem lokalem NVMe halten, und genau das nimmt Last vom oft teureren, langsameren gemeinsamen Storage.

Trace Flags 1117/1118 — nur noch Geschichte (meistens)

Wer ältere Anleitungen liest, stößt unweigerlich auf die Empfehlung, die Trace Flags 1117 und 1118 zu setzen. Das war auf SQL Server 2014 und älter auch richtig: 1117 sorgte für gemeinsames Wachstum aller Dateien einer Gruppe, 1118 für uniforme Extents gegen Contention. Seit SQL Server 2016 ist dieses Verhalten für tempdb fest eingebaut — die Flags sind dort überflüssig und sollten nicht mehr gesetzt werden. Betreibst du noch eine ältere Version, gehören beide aktiviert; auf allem ab 2016 ist das Thema schlicht erledigt. Ein gutes Beispiel dafür, warum man Konfigurations-Tipps immer gegen die eigene Version prüfen sollte, statt sie blind zu übernehmen.

Memory-Optimized Metadata — die letzte Engstelle

Selbst mit perfekter Dateianzahl blieb lange eine tempdb-Engstelle bestehen: die Contention auf den Metadaten, also den internen Systemtabellen, die temporäre Objekte verwalten. Bei Workloads, die massenhaft kurzlebige temporäre Tabellen erzeugen, wurde diese Verwaltung selbst zum Nadelöhr. Seit SQL Server 2019 löst das Feature Memory-Optimized Tempdb Metadata das Problem, indem es diese Systemtabellen in latch-freie, speicheroptimierte Strukturen verlegt. Aktiviert per ALTER SERVER CONFIGURATION und einem Neustart, ist es bei sehr hoher tempdb-Last oft der entscheidende Schritt — bei moderater Last dagegen unnötig, und es gibt einige Einschränkungen (etwa bei bestimmten Operationen über speicheroptimierte Tabellen). Ein Feature für die gezielte Anwendung, nicht für die Gießkanne.

Was du auf keinen Fall tun solltest

Tempdb-Konfiguration in der Routine

Tempdb richtig aufzustellen ist überwiegend eine einmalige Aufgabe — einmal sauber konfiguriert, läuft sie. Drei Punkte gehören trotzdem in die laufende Pflege: Erstens, die tempdb-Konfiguration in den Health Check aufnehmen — Dateianzahl, gleiche Größe und Autogrow gehören zu den Konfigurationswerten, die ein guter Selbsttest mitprüft. Zweitens, Autogrow-Ereignisse überwachen: Wächst tempdb im Betrieb regelmäßig, ist die Grunddimensionierung zu klein und gehört nach oben korrigiert. Drittens, bei jedem Hardware-Wechsel die Kernzahl neu bewerten — eine Maschine mit mehr Kernen kann von mehr tempdb-Dateien profitieren, und die Dateianzahl wandert beim Umzug nicht automatisch mit. Wie tempdb in das größere Bild der proaktiven Wartung passt, zeigt der Health-Check-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Tempdb-Architektur, Allokations-Mechanik und die Konfigurations-Feinheiten füllen in der Buchreihe „SQL Server in der Praxis“ ein eigenes Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Beiträge im Notarztwagen

Tempdb-Konfiguration hat enge Nachbarn — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege zur richtig konfigurierten tempdb

Selbst-Diagnose-Kit

Tempdb-Konfiguration ist die klassische Selbstmach-Aufgabe mit großem Hebel — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Ist-Zustand der Dateien, Contention-Nachweis, Konfigurations-Vorlagen für Dateianzahl und Größe — plus die Fünf-Stellschrauben-Checkliste zum Ausdrucken und einen Dateianzahl-Rechner auf Basis deiner Kernzahl. Damit stellst du tempdb in einem Wartungsfenster ein für alle Mal richtig auf.

Festpreis-Analyse

Dein Server wird unter Last zäh, obwohl CPU und Speicher Reserven zeigen, und du vermutest tempdb als heimlichen Flaschenhals? Die Festpreis-Analyse schafft Klarheit: Ich prüfe die komplette tempdb-Aufstellung gegen die aktuelle Workload — Dateianzahl, Größe, Storage, Contention-Nachweis, Versions-Features — und liefere einen Bericht mit konkreter Soll-Konfiguration und priorisierten Maßnahmen. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn tempdb gerade jetzt zum Problem geworden ist — volläuft oder unter Contention den ganzen Server lähmt: anrufen. Halte einen Zugang mit den nötigen Rechten bereit und die Kernzahl der Maschine. Meist lässt sich die akute Lage entschärfen und die saubere Konfiguration danach ins nächste Wartungsfenster legen.

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 sollte ich anlegen?

Die etablierte Faustregel: eine Datendatei je CPU-Kern bis maximal acht. Hat der Server acht oder weniger Kerne, also je Kern eine Datei; hat er mehr, startest du trotzdem mit acht und erhöhst nur dann in Vierer-Schritten, wenn die Allokations-Contention nachweisbar bestehen bleibt. Der Grund für mehrere Dateien ist nicht mehr Platz, sondern weniger Contention: Die Systemseiten zur Speicherverwaltung (PFS, GAM, SGAM) liegen je Datei getrennt vor, sodass parallele Zugriffe sich auf mehrere Dateien verteilen statt sich auf einer zu drängeln. Seit SQL Server 2016 schlägt das Setup während der Installation bereits eine sinnvolle Anzahl vor.

Wie groß sollte tempdb sein?

Groß genug, dass sie im Normalbetrieb nicht wachsen muss — denn jedes Autogrow-Ereignis kostet Zeit und kann unter Last zu Wartezeiten führen. Statt klein zu starten und den Server wachsen zu lassen, dimensionierst du tempdb vorab auf die Größe, die deine Arbeitslast realistisch braucht, und lässt Autogrow nur als Sicherheitsnetz aktiviert. Die richtige Größe ermittelst du durch Beobachtung über einen vollen Lastzyklus inklusive der großen Monats- und Quartalsläufe. Wichtig: Alle Dateien müssen exakt gleich groß sein, sonst verteilt der Proportional-Fill-Algorithmus die Last ungleich und der Effekt mehrerer Dateien verpufft.

Was bewirken Trace Flag 1117 und 1118?

Diese beiden Trace Flags steuerten früher zwei wichtige tempdb-Verhaltensweisen: 1117 sorgte dafür, dass alle Dateien einer Dateigruppe gemeinsam wachsen (damit sie gleich groß bleiben), und 1118 erzwang die Verwendung uniformer Extents statt gemischter (was Allokations-Contention reduziert). Seit SQL Server 2016 ist dieses Verhalten für tempdb fest eingebaut und Standard — die Trace Flags sind dort also überflüssig. Relevant sind sie nur noch, wenn du eine ältere Version als 2016 betreibst; dann gehören beide gesetzt. Auf modernen Versionen ist das Thema schlicht erledigt, was die tempdb-Konfiguration deutlich vereinfacht hat.

Was ist Memory-Optimized tempdb Metadata?

Ein Feature seit SQL Server 2019, das die internen Systemtabellen von tempdb (die Metadaten) in speicheroptimierte, latch-freie Strukturen verlegt. Damit verschwindet die Metadaten-Contention — die letzte große tempdb-Engstelle, die selbst mit optimaler Dateianzahl bestehen blieb, weil sie nicht die Datenseiten, sondern die Verwaltungstabellen betraf. Aktiviert wird es per ALTER SERVER CONFIGURATION mit anschließendem Neustart. Sinnvoll ist es bei sehr hoher tempdb-Last mit massenhaft temporären Objekten; bei moderater Last bringt es wenig und es gibt einige Einschränkungen zu beachten. Für hoch belastete OLTP-Systeme ist es aber oft der entscheidende Schritt.

Auf welchem Storage gehört tempdb?

Auf das schnellste, latenzärmste Storage, das verfügbar ist — idealerweise ein eigenes, von Daten- und Logdateien getrenntes Flash- oder NVMe-Volume. Tempdb hat ein I/O-Profil, das Flash maximal belohnt: viele kleine, zufällige Zugriffe durch Sortierungen, Spills und den Version Store. Eine Besonderheit macht die Storage-Wahl einfacher als bei anderen Datenbanken: Tempdb wird bei jedem Dienststart komplett neu erstellt und muss weder gesichert noch repliziert werden. Deshalb ist selbst in einem Failover-Cluster lokales NVMe für tempdb unkritisch und oft die beste Wahl — sie muss beim Failover nicht mitwandern.

Sollte tempdb autogrow aktiviert haben?

Ja, aber nur als Sicherheitsnetz, nicht als Wachstumsstrategie. Die Idee ist, tempdb vorab groß genug zu dimensionieren, dass sie im Normalbetrieb nie wachsen muss — und Autogrow nur für den Ausnahmefall aktiviert zu lassen, damit eine unerwartete Lastspitze die Instanz nicht zum Stillstand bringt. Wenn Autogrow greift, sollte der Zuwachs in festen, ausreichend großen Schritten erfolgen (kein winziger Prozentwert), und alle Dateien müssen mit identischem Autogrow konfiguriert sein, damit sie gleich groß bleiben. Häufige Autogrow-Ereignisse im Betrieb sind ein Warnsignal: Dann ist die Grunddimensionierung zu klein gewählt.

Wie verschiebe ich tempdb auf andere Dateien?

Über ALTER DATABASE tempdb MODIFY FILE mit dem neuen Pfad je Datei — die Änderung wird aber erst beim nächsten Dienstneustart wirksam, weil tempdb dann ohnehin neu erstellt wird. Der Ablauf: neuen Pfad per ALTER DATABASE setzen, SQL-Dienst neu starten, prüfen ob tempdb am neuen Ort liegt, dann die alten Dateien entfernen. Über denselben Mechanismus änderst du auch die Anzahl der Dateien (neue per ADD FILE hinzufügen) oder ihre Größe. Da jede Strukturänderung an tempdb einen Neustart braucht, plant man sie sinnvollerweise gebündelt in ein Wartungsfenster — einmal richtig statt mehrfach neu starten.