In den vergangenen SQL Server-Versionen hat Microsoft die Parallelität und Skalierbarkeit der tempdb-Datenbank verbessert. Welche Bereiche die Verbesserungen umfassen und welche Konfliktbereiche wie behoben wurden wird in diesem Artikel näher erläutert.
Ab SQL Server 2016 beziehen sich mehrere Verbesserungen auf Best Practices im Einrichtungsprozess, d. h. wenn mehrere tempdb-Datendateien vorhanden sind, werden alle Dateien automatisch um den gleichen Betrag vergrößert.
Darüber hinaus hat Microsoft ab SQL Server 2019 die speicheroptimierte Metadatenfunktion zu tempdb hinzugefügt und die meisten PFS-Konflikte mit gleichzeitigen PFS-Updates beseitigt.
In SQL Server 2022 adressiert Microsoft nun einen weiteren gemeinsamen Konfliktbereich, indem es gleichzeitige Aktualisierungen der Global Allocation Map (GAM) und der Shared Global Allocation Map (SGAM) einführt. Die Funktion „Gleichzeitige GAM-Updates“ in SQL Server 2022 fügt die Funktion für gleichzeitige GAM- und SGAM-Updates hinzu, um tempdb-Konflikte zu vermeiden. Dadurch werden Kunden-Workloads viel skalierbarer und bieten einen noch besseren Durchsatz.
SQL Server hat tempdb in jeder einzelnen Version verbessert und SQL Server 2022 ist da keine Ausnahme.
Kurz zu tempdb
Tempdb ist eine Systemdatenbank, die allen Benutzern zur Verfügung steht, die mit einer Instanz von SQL Server, Azure SQL-Datenbank oder Azure SQL Managed Instance verbunden sind. Wie der Name schon sagt, wurde die tempdb-Datenbank für die temporäre Speicherung entwickelt. Was bedeutet, dass nichts dauerhaft gespeichert werden soll, was in tempdb geschrieben wurde.
Wichtig zu wissen ist, dass SQL Server zwar die tempdb-Datenbank für fast jede SQL Server-Workload verwendet, es aber nur eine tempdb pro SQL Server-Instanz gibt.
tempdb ist eine globale Ressource, die Folgendes enthält:
- Temporäre Benutzerobjekte, die explizit erstellt werden. Dazu gehören globale oder lokale temporäre Tabellen und Indizes, temporär gespeicherte Prozeduren, Tabellenvariablen, Cursor und Tabellen, die in Tabellenwertfunktionen zurückgegeben werden.
- Interne Objekte, die die Datenbank-Engine erstellt. Sie beinhalten:
- Arbeitstabellen zum Speichern von Zwischenergebnissen für Spools, Cursor, Sortierungen und temporäre Speicherung großer Objekte (LOB).
- Arbeitsdateien für Hash-Join- oder Hash-Aggregat-Operationen.
- Sortierzwischenergebnisse für Vorgänge wie das Erstellen oder Neuerstellen von Indizes (wenn SORT_IN_TEMPDB angegeben ist) oder bestimmte GROUP BY-, ORDER BY- oder UNION-Abfragen.
- Jedes interne Objekt verwendet mindestens neun Seiten. Eine IAM-Seite und einen achtseitigen Extent. Weitere Informationen zu Seiten und Blöcke finden Sie unter Seiten und Blöcke.
- Version stores sind Sammlungen von Daten-Seiten, die Informationen über einzelne Zeilen bereitstellen und die Versionierung auf Zeilen-Ebene ermöglichen. Hierbei unterscheidet man zwischen zwei unterschiedlichen Typen: (1) ein sog. gemeinsamer oder geteilter version store, oder (2) ein sog. online-index-build version store. Die version stores umfassen:
- Zeilenversionen, die durch Datenänderungstransaktionen in einer Datenbank generiert werden, die READ COMMITTED über Zeilenversionsisolations- oder Snapshot-Isolationstransaktionen verwendet.
- Zeilenversionen, die durch Datenänderungstransaktionen für Funktionen wie Online-Indexoperationen, Multiple Active Results Sets (MARS) und AFTER-Trigger generiert werden.
Vorgänge innerhalb von tempdb werden minimal protokolliert, sodass Transaktionen rückgängig gemacht werden können. tempdb wird bei jedem Start von SQL Servern neu erstellt, sodass das System immer mit einer sauberen Kopie der Datenbank startet. Temporäre Tabellen und gespeicherte Prozeduren werden beim Trennen automatisch gelöscht und es sind keine Verbindungen aktiv, wenn das System heruntergefahren wird.
tempdb muss nie von einer Sitzung von SQL Server zu einer anderen gespeichert werden. Sicherungs- und Wiederherstellungsvorgänge sind auf tempdb nicht zulässig.
Tempdb-Performance-Herausforderungen
In der Vergangenheit war tempdb einer dieser häufigen Schmerzpunkte in SQL Server. Warum war es ein Schmerzpunkt? Nun, die Nutzung ist einer der Hauptgründe. Durch die Verwendung bezieht sich Microsoft auf das Erstellen von temporären Tabellen und anderen Benutzerobjekten, aber tempdb wird auch intern verwendet, um diese auf die Festplatte zu übertragen, wenn nicht genügend Arbeitsspeicher für einen Prozess verfügbar ist oder eine ungenaue Schätzung vorliegt, die dazu führt, dass SQL Server in tempdb übergeht.
Tempdb workloads
Der Hauptunterschied zwischen tempdb und anderen Datenbanken ist die Arbeitslast. Mit tempdb erstellen und löschen wir ständig Objekte wie temporäre Tabellen. Dies gilt insbesondere in intensiven OLTP-Umgebungen, in denen möglicherweise Threads viele verschiedene Aufgaben erledigen. Die Auswirkungen werden verstärkt, wenn sie bereits Ressourcenkonflikte auf dem System sehen.
