dbatools 2.8.4 kann mit `Set-DbaTempDbConfig` eine Verkleinerung der TempDB-Dateien erzwingen. Das hilft bei einer falschen Überdimensionierung, macht Shrink aber nicht zur Routine: TempDB bedient Sortierung, Version Store, Spills und interne Engine-Arbeit.

Bedeutung für den Betrieb

Zuerst ist die Wachstumsursache zu klären. Ein einmaliger Indexlauf, Version-Store-Rückstau, schlechter Plan oder bewusstes Pre-Sizing verlangt andere Maßnahmen als dauerhafte Fehlkonfiguration; Dateinutzung, Autogrowth und aktive Requests liefern die Belege.

Technische Infrastruktur für TempDB-Shrink-Planung
TempDB-Shrink-Planung beginnt mit vollständigem Bestand und klaren Betriebsgrenzen.

Der Change definiert Zielgröße, Dateizahl, Wachstumswert, Wartungsfenster und Abbruchkriterien. Online-Verkleinerung wird gegen Neustart oder Konfigurationswechsel abgewogen und unter realer Last auf Blocking, I/O und Latenz geprüft.

Automation muss Ist- und Zielwerte, aktive Nutzung, Freigabe und Ergebnis protokollieren. `-Force` gehört nicht in einen generischen Desired-State-Lauf, der stabile Vorallokation regelmäßig wieder entfernt.

Betriebliche Prüfung für TempDB-Shrink-Planung
Der Change endet erst nach der Validierung von TempDB-Shrink-Planung unter realen Bedingungen.

Praktische Konsequenz

Die Konsequenz: Shrink bleibt eine begründete Ausnahme. Ursache beheben, sicheren Zielzustand wählen und danach Regrowth beobachten; freier Speicher allein ist kein Erfolgskriterium.