Wie der Name schon sagt, ist TempDB ein temporärer Arbeitsbereich, der von SQL Server zum Erstellen und Speichern von temporären und temporären Objekten benötigt wird.
TempDB ist ein bedeutendes Rädchen im gesamten SQL Server-Apparat und als temporärer Arbeitsbereich – die darin enthaltenen Daten sind vorübergehender Natur. Mit anderen Worten, Ihre SQL Server-Instanz erstellt TempDB bei jedem Neustart neu – wodurch sie sich selbst einen sauberen Notizblock gibt, mit dem sie arbeiten kann.
- temporäre Objekte, die durch Benutzeranfragen ausgelöst werden
- Objekte, die von internen Systemprozessen benötigt werden
- Zeilenversionierungsinformationen
Wenn TempDB nicht optimal konfiguriert ist, kann es natürlich zu Betriebsengpässen und Leistungseinbußen kommen. Sie fragen sich vielleicht, warum Ihre Abfragen mit komplexen Verknüpfungen und Sortiervorgängen nicht so schnell Ergebnisse liefern wie erwartet.
Es gibt keine einfache Möglichkeit, die Best Practices für die Optimierung von TempDB zu verallgemeinern, die Szenarien sind zu unterschiedlich und was in einer bestimmten Situation funktioniert, funktioniert möglicherweise nicht in einer anderen. Selbst wenn Ihre Datenbank in Produktion gegangen ist, ist es immer eine gute Idee, Ihr TempDB-Setup weiterhin zu überprüfen, um sicherzustellen, dass es so konfiguriert ist, wie es sein sollte.
Eines der schwerwiegendsten Probleme bei der Datenbankleistung ist der TempDB-Konflikt. Dies geschieht, wenn mehrere Ressourcen TempDB erfordern, aber nur auf eine einzige TempDB-Datendatei zugegriffen werden kann.
TempDB-Konflikte können schwerwiegende Leistungsprobleme verursachen und werden oft als normale Blockierung aufgrund von Datenbanksperren missverstanden. Oft handelt es sich tatsächlich um zwischengespeicherte Konflikte auf den Zuordnungsseiten durch gleichzeitige Prozesse. Dies kann zu Engpässen führen, da jeder Prozess darauf wartet, an der Reihe zu sein. Da die Wende nicht schnell genug kommt, müssen die zugrunde liegenden Verbindungszeitüberschreitungen und die Prozesse freigegeben werden.
Was bekommst du? Ein virtueller Stau blockierter Prozesse.
Wie lösen Sie TempDB-Konflikte und optimieren die Leistung von SQL Server? Werfen wir einen Blick auf die Grundlagen und arbeiten uns von dort aus vor.
Anzahl der Datendateien – Wie viele sollte ich haben?
Wenn Sie SQL Server einrichten und die Standardkonfiguration beibehalten, haben Sie nur eine einzige Datendatei für TempDB. Geben Sie sich nicht mit dieser Konfiguration zufrieden.
Eine der oft angepriesenen Faustregeln ist eine einzelne Datendatei pro Kern. Aber gehen Sie in diesem Fall mit Vorsicht vor, wenn Ihr Server 12 Kerne hat, dann verwenden Sie nicht 12 TempDB-Datendateien, es sei denn, dies ist durch die Anwendungs- und Lastanforderungen gerechtfertigt.
Angesichts der heutigen Hardwarekonfigurationen ist es die beste Option, mit 8 gleich großen primären Datendateien zu beginnen und zu sehen, ob das Konfliktproblem behoben ist. Arbeiten Sie sich nach oben vor und fügen Sie bei Bedarf weitere vier Dateien hinzu. Der Installations- und Einrichtungsassistent von SQL Server 2016 verfügt über eine integrierte Funktion, die sicherstellt, dass Sie über eine ausreichende Anzahl von TempDB-Datendateien verfügen, indem die Anzahl der CPU-Kerne erkannt und automatisch die entsprechende Anzahl von TempDB-Datendateien erstellt wird.
Größe spielt eine Rolle – Wie sollten die Datendateien für die Größe konfiguriert werden?
Nachdem wir nun die Anzahl der Dateien behandelt haben, werfen wir einen Blick auf die empfohlene Größe jeder Datei. Die Standardgröße beträgt 8 MB, was SQL Server insgesamt 64 MB TempDB-Speicherplatz zur Verfügung stellt, was für die meisten Produktionsumgebungen nicht ausreicht. Die Beibehaltung der automatischen Vergrößerung ist ebenfalls eine Option, aber SQL Server muss anhalten und bei Bedarf mehr Speicherplatz für die TempDB-Dateien zuweisen – was zu einem erheblichen Mehraufwand für SQL Server während eines Produktionslaufs führt.
Es wird empfohlen, Dateien beizubehalten, und der anfänglich für jede Datei erforderliche Speicherplatz sollte etwa 80 bis 90 % des Volumes betragen, auf dem die TempDB gespeichert ist. Die 10 bis 20 % Festplattenspeicher bleiben für den betriebssystembasierten virtuellen Speicher übrig.
Mit anderen Worten, passen Sie die Größe der Datendateien während des Setups an oder ändern Sie die Größe der Dateien in der Produktionsumgebung. Dadurch wird sichergestellt, dass genügend Speicherplatz für TempDB zugewiesen wird. Es wird an dieser Stelle immer empfohlen, die Option Autogrowth aktiviert zu lassen, aber versuchen Sie im Idealfall sicherzustellen, dass SQL Server nicht zu oft zusätzlichen Speicherplatz zuweisen muss.
Eine interessante Tatsache, vor SQL Server 2017 war es zum Zeitpunkt der Einrichtung nicht möglich, mehr als 1 GB pro TempDB-Datendatei zuzuweisen. Mit der neuesten Version ist es möglich, während des Setups bis zu 256 GB für eine TempDB-Datendatei zuzuweisen.
Das bringt uns zur nächsten Frage:
Wo bewahre ich die TempDB-Datendateien auf?
Vor SQL Server 2012 musste sich TempDB im Falle einer Clusterumgebung auf Datenträgern befinden, die von der Clusterumgebung gemeinsam genutzt werden, wie ein Storage Area Network (SAN). Ab SQL Server 2012 ist es möglich, die TempDB-Datendateien auf einem SSD-basierten lokalen Speicher zu speichern. Dadurch wird viel Datenverkehr zwischen dem gemeinsam genutzten SAN und der SQL Server-Instanz reduziert.
In den meisten Fällen ist die beste Option für den Speicherort von TempDB eine dedizierte lokale SSD. Wenn dies nicht möglich ist, sollten Sie wahrscheinliche Leistungsprobleme lösen, indem Sie es auf einem eigenen dedizierten Volume mit ausreichend vorab zugewiesenem Speicherplatz aufbewahren. Stellen Sie sicher, dass Sie den Festplattenzustand ständig überwachen, damit Lese- und Schreibvorgänge auf einem optimalen Niveau ausgeführt werden.
Idealerweise sollten die Medien angesichts der Serverkonfiguration, der Anwendungsanforderungen und nicht zuletzt des zugewiesenen Budgets so schnell wie möglich sein.
Nachdem wir uns nun die Grundlagen angesehen haben, schauen wir uns relevante und willkommene Ergänzungen zu verschiedenen SQL Server-Ergänzungen nach SQL Server 2012 an.
Was ist sonst noch neu?
SQL-Server 2016
Dedizierte Registerkarte während der Einrichtung
- Mit dieser Edition hat SQL Server eine dedizierte Registerkarte für die TempDB-Konfiguration während des Setup-Workflows
- Der Installations- und Einrichtungsassistent von SQL Server 2016 verfügt über eine integrierte Funktion, die sicherstellt, dass Sie zum Zeitpunkt der Installation von SQL Server über eine ausreichende Anzahl von TempDB-Datendateien verfügen. Es erkennt die Anzahl der CPU-Kerne und erstellt automatisch TempDB-Datendateien, vorbehaltlich eines Maximums von 8. Sie können diese Anzahl erhöhen, nachdem Sie SQL Server eingerichtet haben.
Sofortige Dateiinitialisierung
- SQL Server muss während der Ersteinrichtung sowie bei wachsender Dateigröße in einem Produktionslauf Speicherplatz für TempDB zuweisen. Diese Zuordnung kann auf zwei Arten erfolgen. Die erste Möglichkeit besteht darin, ungenutzten Speicherplatz zu initialisieren, indem Nullen geschrieben werden, bevor der Speicherplatz zugewiesen wird. Die zweite Möglichkeit besteht in der sofortigen Zuweisung von Dateispeicherplatz für das TempDB-Wachstum.
- Bei der ersten Methode muss SQL Server einen datenträgerintensiven Vorgang ausführen, indem er jeden logischen Datenträgercluster initialisiert. Bei dieser Methode müssen die auf dem Server ausgeführten Prozesse, die TempDB benötigen, möglicherweise warten, wodurch ein Engpass entsteht.
- Wenn Sie sich dafür entscheiden, Dateispeicherplatz stattdessen sofort zuzuweisen, weist der SQL-Server sofort Speicherplatz für die automatische Vergrößerung zu, ohne den Speicherplatz zu initialisieren. Dies reduziert die Festplatten-E/A jedes Mal, wenn eine Autogrowth-Anforderung besteht, und gewährleistet einen besseren Durchsatz und eine bessere Leistung. Obwohl es in früheren Ausgaben möglich war, IFI einzuschalten, war dies ein umständlicher Vorgang. In dieser Edition von SQL Server ist es einfacher, IFI zum Zeitpunkt der Servereinrichtung einzurichten.
- Trace-Flags 1117 und 1118 sind redundant
SQL-Server 2017
- Vor SQL Server 2017 war es zum Zeitpunkt der Einrichtung nicht möglich, mehr als 1 GB pro TempDB-Datendatei zuzuweisen, was bedeutet, dass die Größe der TempDB-Datei nach Abschluss der Einrichtung erhöht werden musste. Mit dieser Version ist es möglich, während des Setups bis zu 256 GB für eine TempDB-Datendatei zuzuweisen.
TempDB überwachen
Es kann schwierig sein, den Überblick über TempDB zu behalten. Wie können Sie feststellen, ob Sie TempDB-Konflikte haben? Was wird Benutzerobjekten, Versionsspeicher oder internen Objekten zugewiesen? Wie entwickeln sich diese im Laufe der Zeit? Welche Sitzungen verbrauchen TempDB und in welchem Umfang? Spotlight Cloud macht die Beantwortung dieser Fragen einfach. Es überwacht rund um die Uhr alle Aspekte der Leistung Ihres SQL-Servers und bietet umfassende Analyse-Workflows, um jedes Leistungsproblem anzugehen. Verfolgen Sie Ihre TempDB im Laufe der Zeit und erhalten Sie automatisierte Expertenratschläge zur Konfiguration.
Als SaaS-Lösung ist Spotlight Cloud einfach einzurichten und zu konfigurieren. Es speichert die Leistungsdaten von bis zu einem Jahr und gibt unschlagbare Tuning-Einblicke. Leistungsprobleme können mit der Ursachenanalyse in Sekundenschnelle behoben werden. Verschwenden Sie keine Zeit mehr damit, sich durch komplexe Skripte zu wühlen – starten Sie jetzt Ihre 30-Tage-Testversion. Erstklassige SQL Server-Leistungsüberwachung beginnt jetzt.
