In meinem vorherigen Artikel über SQL Server-Systemdatenbanken haben wir uns über jede Systemdatenbank informiert, die Teil der SQL Server-Installation ist. Der aktuelle Artikel konzentriert sich auf häufig auftretende Probleme rund um die tempdb-Datenbank und wie man sie richtig löst.
SQL Server TempDB
Wie der Name dieser Systemdatenbank schon sagt, tempdb enthält temporäre Objekte von SQL Server erstellt. Sie beziehen sich auf mehrere Vorgänge und fungieren als globaler Arbeitsbereich für alle Benutzer, die sich mit SQL Server-Instanzen verbinden.
Die Tempdb-Datenbank enthält die folgenden Objekttypen, während Benutzer ihre Operationen ausführen:
- Temporäre Objekte werden explizit von Benutzern erstellt. Sie können entweder lokale oder globale temporäre Tabellen und Indizes, Tabellenvariablen, in Tabellenwertfunktionen verwendete Tabellen und Cursor sein.
- Interne Objekte, die von der Datenbank-Engine erstellt wurden, wie
- Arbeitstabellen, die Zwischenergebnisse für Spools, Cursors, Sortierungen und temporäre große Objekte (LOB) speichern.
- Dateien bearbeiten, während Hash-Join- oder Hash-Aggregat-Operationen durchgeführt werden.
- Zwischensortierergebnisse beim Erstellen oder Neuerstellen von Indizes, wenn SORT_IN_TEMPDB auf ON gesetzt ist, und andere Vorgänge wie GROUP BY-, ORDER BY- oder SQL UNION-Abfragen.
- Versionsspeicher, die die Zeilenversionierungsfunktion unterstützen, entweder der allgemeine Versionsspeicher oder der Online-Index-Build-Versionsspeicher verwendet die tempdb-Datenbankdateien.
Die Tempdb-Datenbank wird jedes Mal erstellt, wenn der SQL Server-Dienst gestartet wird. Daher kann die Zeit der Erstellung der tempdb-Datenbank als ungefähre Startzeit des SQL Server-Dienstes betrachtet werden. Wir können es anhand von sys.databases DMV identifizieren Verwenden Sie die unten gezeigte Abfrage:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Der eigentliche Start des SQL Server-Dienstes umfasst jedoch das Starten aller Systemdatenbanken in einer bestimmten Reihenfolge. Dies kann etwas früher als die Erstellungszeit von tempdb geschehen. Wir können den Wert mit sys.databases DMV abrufen indem Sie die folgende Abfrage auf sys.dm_os_sys_info DMV ausführen .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
Die ms_ticks Spalte gibt die Anzahl der Millisekunden seit dem Start des Computers oder Servers an. Die sqlserver_start_time_ms_ticks Spalte gibt die Anzahl der Millisekunden seit den ms_ticks an Nummer, als der SQL Server-Dienst gestartet wurde.
Weitere Informationen über die Reihenfolge der Datenbanken, die beim Starten der SQL Server-Dienste gestartet wurden, finden Sie im SQL Server-Fehlerprotokoll.
Erweitern Sie in SSMS Verwaltung > SQL Server-Fehlerprotokolle > öffnen Sie die aktuelle Fehlerprotokoll. Wenden Sie den Start an Datenbank hoch filtern und auf Datum klicken um es in aufsteigender Reihenfolge zu sortieren:
Wir können sehen, dass die Master-Datenbank beim Starten des SQL Server-Dienstes zuerst gestartet wurde. Dann folgten alle Benutzerdatenbanken und alle anderen Systemdatenbanken. Schließlich startete die tempdb. Sie können diese Informationen auch programmgesteuert abrufen, indem Sie xp_readerrorlog ausführen Systemprozedur:
Hinweis :Beide oben genannten Ansätze zeigen möglicherweise nicht die erforderlichen Informationen an, wenn der SQL Server-Dienst nicht kürzlich neu gestartet wurde und das SQL Server-Fehlerprotokoll wiederverwendet wurde, wodurch möglicherweise ältere Fehlerprotokolle in ältere Dateien verschoben wurden. In diesem Fall müssen wir möglicherweise die Daten in den archivierten SQL Server-Fehlerprotokolldateien scannen.
Häufig auftretende Probleme in der SQL TempDB-Datenbank
Da tempdb einen globalen Arbeitsbereich für alle Benutzersitzungen oder -aktivitäten bereitstellt, kann es zu einem Leistungsengpass für Benutzervorgänge werden, wenn es nicht sorgfältig konfiguriert wird. In meinem vorherigen Artikel haben wir die empfohlenen Best Practices zur Implementierung in der tempdb-Datenbank besprochen. Auch nach der Implementierung können jedoch häufig Probleme auftreten:
- Ungleichmäßiges Dateiwachstum über tempdb-Datendateien hinweg.
- Tempdb-Datendateien wachsen zu einem enormen Wert und müssen Tempdb verkleinern.
Ungleichmäßiges Dateiwachstum bei TempDB-Datendateien
Ab SQL Server 2000 lautet die Standardempfehlung, mehrere Datendateien basierend auf der Anzahl der im Server verfügbaren logischen Kerne zu haben.
Wenn wir mehrere Datendateien haben, z. B. 4 tempdb-Datendateien wie in der Abbildung unten, erfolgt die automatische Vergrößerung der tempdb-Datendateien um 64 MB im Round-Robin-Verfahren, beginnend mit tempdev> temp2> temp3> temp4> tempdev> und so weiter.
Wenn eine der Dateigrößen aus irgendeinem Grund nicht automatisch wachsen kann, führt dies dazu, dass bestimmte Dateien im Vergleich zu anderen Dateien sehr groß sind. Dies führt zu einer zusätzlichen Überlastung großer Dateien und zu einer negativen Auswirkung auf die Leistung der tempdb-Datenbank.
Wir müssen manuell sicherstellen, dass alle tempdb-Datendateien zu jedem Zeitpunkt manuell die gleiche Größe haben, um Konflikte oder Leistungsprobleme bis SQL Server 2014 zu vermeiden. Microsoft hat dieses Verhalten ab SQL Server 2016 und späteren Versionen geändert, indem einige Funktionen implementiert wurden, die es sein werden später in diesem Artikel besprochen.
Um die oben genannten Leistungsprobleme zu überwinden, hat SQL Server 2 Ablaufverfolgungs-Flags eingeführt mit dem Namen 1117 und 1118 um die Konfliktprobleme um tempdb zu vermeiden.
- Trace-Flag 1117 – aktiviert die automatische Vergrößerung aller Dateien innerhalb einer einzelnen Dateigruppe
- Trace-Flag 1118 – aktiviert UNIFORM FULL EXTENTS für tempdb
Trace-Flag 1117
Wenn das Ablaufverfolgungsflag 1117 nicht aktiviert ist und tempdb mit mehreren Datendateien mit gleichmäßiger Größe konfiguriert ist und Datendateien automatisch vergrößert werden müssen, versucht SQL Server standardmäßig, die Dateigrößen in einem Round-Robin-Verfahren zu erhöhen, wenn alle Dateien. Wenn die Größe der Datendateien nicht gleichmäßig ist, versucht SQL Server, die Größe der größten Datendatei von tempdb zu erhöhen, und verwendet diese größere Datei für die meisten Benutzervorgänge, was zu Problemen mit tempdb-Konkurrenzen führt..
Um dieses Problem zu beheben, hat SQL Server das Ablaufverfolgungsflag 1117 eingeführt. Wenn eine Datei in einer Dateigruppe nach der Aktivierung automatisch vergrößert werden muss, werden alle Dateien in dieser Dateigruppe automatisch vergrößert. Es behebt die tempdb-Konfliktprobleme. Der Haken an der Sache ist jedoch, dass sobald das Trace-Flag 1117 aktiviert ist, die automatische Vergrößerung auch für alle Benutzerdatenbanken konfiguriert ist.
Trace-Flag 1118
Das Trace-Flag 1118 wird verwendet, um UNIFORM FULL EXTENTS zu aktivieren. Gehen wir einen Schritt zurück, um zu verstehen, wie SQL Server die Daten von Basic speichert.
Seite ist die grundlegende Speichereinheit in SQL Server mit einer Größe von 8 Kilobyte (KB).
Ausdehnung ist ein Satz von 8 physisch zusammenhängenden Seiten mit einer Größe von 64 KB (8 * 8 KB). Basierend darauf, wie viele Objekte oder Eigentümer die Daten in einem Extent speichern, kann Extent klassifiziert werden in:
- Einheitliche Grenzen sind 8 zusammenhängende Seiten, die von einem einzelnen Objekt oder Eigentümer verwendet oder aufgerufen werden;
- Gemischt Ausmaße – sind 8 zusammenhängende Seiten, die von mindestens 2 und höchstens 8 Objekten oder Eigentümern verwendet oder aufgerufen werden
Durch Aktivieren des Trace-Flags 1118 kann tempdb einheitliche Extents haben, was zu einer besseren Leistung führt.
So aktivieren Sie Ablaufverfolgungs-Flags 1117 und 1118
Ablaufverfolgungsflags können über mehrere Ansätze aktiviert werden. Sie können den geeigneten Weg aus den folgenden Optionen definieren:
Startparameter des SQL Server-Dienstes
Auch nach dem Neustart des SQL-Dienstes dauerhaft verfügbar. Es wird empfohlen, die Trace-Flags 1117 und 1118 über die Startparameter des SQL Server-Dienstes zu aktivieren .
Öffnen Sie SQL Server Configuration Manager und klicken Sie auf SQL Server Services um die verfügbaren Dienste auf diesem Server aufzulisten:
- Klicken Sie mit der rechten Maustaste auf SQL Server (MSSQLSERVER) > Eigenschaften > Startparameter .
- Geben Sie –T ein in das leere Feld ein, um das Trace Flag anzugeben .
- Geben Sie die Werte 1117 an und 1118 wie unten gezeigt.
- Klicken Sie auf Hinzufügen um die Ablaufverfolgungs-Flags als Startparameter hinzuzufügen.
Klicken Sie dann auf OK um die Ablaufverfolgungsflags dauerhaft für diese Instanz von SQL Server hinzuzufügen. Starten Sie den SQL Server-Dienst neu, damit die Änderungen übernommen werden.
DBCC TRACEON (, -1)
Aktivieren Sie ein Ablaufverfolgungsflag global. Der SQL Server-Dienst verliert die Ablaufverfolgungsflags beim Neustart des Diensts. Um ein Trace-Flag global zu aktivieren, führen Sie das folgende Skript in einem neuen Abfragefenster aus:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Aktivieren Sie das Ablaufverfolgungsflag auf Sitzungsebene. Sie gilt nur für die aktuelle Sitzung, die vom Benutzer erstellt wurde. Um ein Trace-Flag auf Sitzungsebene zu aktivieren, führen Sie das folgende Skript in einem neuen Abfragefenster aus:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
Um die Liste der Ablaufverfolgungsflags anzuzeigen, die in einer Instanz von SQL Server aktiviert sind, können wir den DBCC TRACESTATUS verwenden Befehl:
DBCC TRACESTATUS();
Wie wir sehen können, sind Trace Flags 1117 und 1118 in meiner Instanz zusammen mit Sitzung global aktiviert .
Um ein Trace-Flag zu deaktivieren, können wir den DBCC TRACEOFF-Befehl wie folgt verwenden:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
SQL Server 2016 TempDB-Verbesserungen
In den SQL Server-Versionen SQL Server 2000 bis SQL Server 2014 müssen wir die Trace-Flags 1117 und 1118 zusammen mit der vollständigen Überwachung von tempdb aktivieren, um Konfliktprobleme mit tempdb zu vermeiden. Ab SQL Server 2016 und späteren Versionen sind die Trace-Flags 1117 und 1118 standardmäßig implementiert.
Basierend auf meiner persönlichen Erfahrung ist es jedoch besser, tempdb vorab auf eine riesige Größe zu vergrößern, um die Notwendigkeit einer mehrfachen automatischen Vergrößerung zu vermeiden und um ungleichmäßige Dateigrößen oder einzelne Dateien zu eliminieren, die von SQL Server extensiv verwendet werden .
Wir können überprüfen, wie die Trace-Flags 1117 und 1118 in SQL Server 2016 implementiert sind:
Trace-Flag 1117 die das automatische Wachstum aller Dateien innerhalb einer Dateigruppe festlegt, ist jetzt eine Eigenschaft der Dateigruppe . Wir können es konfigurieren, während wir eine neue Dateigruppe erstellen oder eine vorhandene ändern.
Um die automatische Vergrößerungseigenschaft der Dateigruppe zu überprüfen , führen Sie das folgende Skript von sys.filegroups DMV aus :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
So ändern Sie die automatische Vergrößerungseigenschaft der primären Dateigruppe der AdventureWorks-Datenbank , führen wir das folgende Skript entweder mit AUTOGROW_ALL_FILES aus, um alle Dateien gleichermaßen automatisch zu vergrößern, oder mit AUTOGROW_SINGLE_FILE, um die automatische Vergrößerung nur einer einzigen Datendatei zu ermöglichen.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Trace-Flag 1118 die die Eigenschaft Uniform Extent von Datendateien festlegt ist standardmäßig für tempdb und alle Benutzerdatenbanken ab SQL Server 2016 aktiviert . Wir können die Eigenschaften für tempdb nicht ändern, da es jetzt nur die Option Uniform Extent unterstützt.
Für Benutzerdatenbanken können wir diesen Parameter ändern. Die Systemdatenbanken master, model und msdb unterstützen standardmäßig Mixed Extents und können ebenfalls nicht geändert werden.
Verwenden Sie das folgende Skript, um die Eigenschaftswerte der gemischten Seitenzuordnung für Benutzerdatenbanken zu ändern:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
Um die Eigenschaft "Gemischte Seitenzuordnung" zu überprüfen, können wir is_mixed_page_allocation_on abfragen -Spalte aus sys.databases DMV mit dem Wert 0, der eine einheitliche Extent-Seitenzuordnung angibt, und 1, um die gemischte Extent-Seitenzuordnung anzugeben.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
TempDB-Datendateien wachsen zu einem enormen Wert, der eine Verkleinerung von TempDB erfordert
Wenn in SQL Server 2014 oder früheren Versionen die Ablaufverfolgungsflags 1117 und 1118 zusammen mit mehreren für die tempdb-Datenbank erstellten Datendateien nicht richtig konfiguriert sind, werden einige dieser Dateien unweigerlich sehr groß. In diesem Fall versucht ein DBA normalerweise, die tempdb-Datendateien zu verkleinern. Aber es ist ein unsachgemäßes Ansatz, um dieses Szenario zu handhaben.
Es gibt andere Optionen, um die tempdb zu verkleinern.
Betrachten wir die DBCC-Befehle, die Shrink tempdb zur Verfügung stehen, und die Auswirkungen dieser Vorgänge.
DBCC SHRINKDATABASE
Die DBCC SHRINKDATABASE Der Konsolenbefehl funktioniert durch Verkleinern des Endes der Data\Log-Dateien .
Um eine Datenbank erfolgreich zu verkleinern, benötigt der Befehl freien Speicherplatz am Ende der Datei. Wenn am Ende der Datei aktive Transaktionen vorhanden sind, können die Datenbankdateien nicht verkleinert werden.
Die Auswirkungen der Ausführung von DBCC SHRINKDATABASE besteht darin, dass versucht wird, am Ende jeder Datendatei oder Protokolldatei verfügbaren freien Speicherplatz freizugeben, der möglicherweise für zukünftiges Wachstum von Tabellendaten reserviert wurde. Daher kann die Ausführung dieses Befehls zu ungleichmäßigen Dateigrößen führen, die zu tempdb-Konfliktproblemen führen.
Die Syntax zum Verkleinern einer Benutzerdatenbank wäre zum Beispiel die Adventureworks-Datenbank
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);DBCC-SCHRUMPFDATEI
Die DBCC SHRINKFILE Der Konsolenbefehl funktioniert ähnlich wie DBCC SHRINKDATABASE, aber er verkleinert die angegebenen Datenbankdaten oder Protokolldateien .
Wenn Sie feststellen, dass eine bestimmte tempdb-Datendatei sehr groß ist, können wir versuchen, dieses bestimmte Element mit DBCC SHRINKFILE wie unten gezeigt zu verkleinern.
Seien Sie vorsichtig, wenn Sie diesen Befehl für tempdb verwenden, denn wenn eine Datei auf einen niedrigeren oder höheren Wert als andere Datendateien verkleinert wird, wird diese bestimmte Datendatei nicht effektiv verwendet. Oder es wird häufiger verwendet, was zu tempdb-Konfliktproblemen führt.
Die Syntax zum Ausführen des DBCC-SHRINKFILE-Vorgangs für die AdventureWorks-Datendatei auf 1 GB (1024 MB) lautet:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
DBCC-DROPCLEANPUFFER
Die DBCC DROPCLEANBUFFERS Der Befehl console wird verwendet, um alle sauberen Puffer aus dem Pufferpool und Columnstore-Objekte aus dem Columnstore-Objektpool zu löschen .
Führen Sie einfach den folgenden Befehl aus:
DBCC DROPCLEANBUFFERSDBCC FREEPROCACHE
Der DBCC FREEPROCCACHE Befehl löscht den gesamten Ausführungsplan-Cache für gespeicherte Prozeduren .
Der Procedure Execution Plan Cache wird von SQL Server verwendet, um dieselben Prozeduraufrufe schneller auszuführen. Nach dem Ausführen von DBCC FREEPROCCACHE wird der Plan-Cache gelöscht. Daher muss SQL Server diesen Cache erneut erstellen, wenn die gespeicherte Prozedur in der Instanz ausgeführt wird. Es hinterlässt ernsthafte negative Auswirkungen, wenn es in den Produktions-DB-Instanzen ausgeführt wird.
Es wird nicht empfohlen, DBCC FREEPROCCACHE auf der Produktionsdatenbankinstanz auszuführen!
Die Syntax zum Ausführen von DBCC FREEPROCCACHE ist unten:
DBCC FREEPROCCACHEDBCC FREESESSIONCACHE
Der DBCC FREESESSIONCACHE Befehl löscht den Verbindungscache für Verteilungsabfragen aus der SQL Server-Instanz . Dies ist hilfreich, wenn viele verteilte Abfragen auf einer bestimmten SQL Server-Instanz ausgeführt werden.
Die Syntax zum Ausführen von DBCC FREESESSIONCACHE wäre:
DBCC FREESESSIONCACHEDBCC FREESYSTEMCACHE
Der DBCC FREESYSTEMCACHE Befehl löscht alle ungenutzten Cache-Einträge aus dem gesamten Cache . SQL Server tut dies standardmäßig, um mehr Arbeitsspeicher für neue Vorgänge verfügbar zu machen. Wir können es jedoch manuell mit dem folgenden Befehl ausführen:
DBCC FREESYSTEMCACHEWie wir wissen, speichert tempdb alle temporären Benutzerobjekte oder internen Objekte, einschließlich Ausführungsplan-Cache, Pufferpooldaten, Sitzungs-Caches und System-Caches. Daher hilft die Ausführung der obigen 6 DBCC-Befehle dabei, die tempdb-Datendateien zu löschen, die den normalen Verkleinerungsprozess verhindern.
Obwohl wir Schritte zum Verkleinern von tempdb über verschiedene Ansätze durchlaufen haben, sind die empfohlenen Best Practices für den Umgang mit der tempdb-Datenbank unten aufgeführt:
a. Starten Sie die SQL Server-Dienste nach Möglichkeit neu, um die tempdb-Datendateien gleichmäßig neu zu erstellen. Mögliche Auswirkungen wären, dass wir alle Ausführungspläne und andere oben besprochene Cache-Informationen verlieren.
b. Vergrößern Sie tempdb-Datendateien vorab auf eine riesige Dateigröße, die auf dem Laufwerk mit tempdb-Datendateien verfügbar ist. Dadurch wird verhindert, dass SQL Server die Dateigrößen in SQL Server-Versionen 2014 und früher ungleichmäßig erhöht.
c. Wenn SQL Server-Dienste aufgrund von RTO oder RPO nicht neu gestartet werden können, versuchen Sie die obigen DBCC-Befehle, nachdem Sie die Auswirkungen genau verstanden haben.
d. Das Verkleinern von tempdb-Datenbanken oder -Datendateien ist kein empfohlener Ansatz, und tun Sie dies daher niemals in Ihrer Produktionsumgebung, es sei denn, es gibt keine anderen Optionen.
Schlussfolgerung
Wir haben mehr über die Interna der Funktionsweise von tempdb gelernt, sodass wir tempdb für eine bessere Leistung konfigurieren können, um Konfliktprobleme bei tempdb zu vermeiden. Wir haben auch die häufig auftretenden Probleme in tempdb, Maßnahmen, die in SQL Server in verschiedenen Versionen verfügbar sind, und wie man sie effizient handhabt, durchgegangen. Darüber hinaus haben wir untersucht, warum das Verkleinern der tempdb-Datenbank oder von Datendateien beim Umgang mit der tempdb-Datenbank kein empfohlener Ansatz ist.
