tempdb-Datenbank

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

Dieser Artikel beschreibt die tempdb-Systemdatenbank, eine globale Ressource, die allen Benutzern zur Verfügung steht und mit einer Instanz von SQL Server, Azure SQL-Datenbank oder Azure SQL Managed Instance verbunden ist.

Übersicht

Die tempdb-Systemdatenbank ist eine globale Ressource, die Folgendes umfasst:

  • Temporäre Benutzerobjekte, die explizit erstellt werden. Hierzu gehören globale oder lokale temporäre Tabellen und Indizes, temporäre gespeicherte Prozeduren, Tabellenvariablen, in Tabellenwertfunktionen zurückgegebene Tabellen und Cursor.

  • Interne Objekte, die von der Datenbank-Engine erstellt werden. Dazu gehören:

    • Arbeitstabellen, in denen direkte Ergebnisse für Spools, Cursor, Sortierungen und temporäre große Objektspeicher (LOB) gespeichert werden.
    • Arbeitsdateien für Hashjoin- oder Hashaggregatvorgänge.
    • Zwischenergebnisse von Sortierungen bei Vorgängen wie z. B. dem Erstellen oder Neuerstellen von Indizes (wenn SORT_IN_TEMPDB angegeben ist) oder bei bestimmten GROUP BY-, ORDER BY- oder UNION-Abfragen.

    Jedes interne Objekt verwendet mindestens neun Seiten: eine IAM-Seite (Index Allocation Map) und eine achtseitige Erweiterung. Weitere Informationen zu Seiten und Erweiterungen finden Sie unter Seiten und Blöcke.

  • Versionsspeicher. Dies sind Sammlungen von Datenseiten, in denen die Datenzeilen zur Unterstützung von Features für die Zeilenversionsverwaltung gespeichert werden. Es gibt zwei Speichertypen: einen allgemeinen Versionsspeicher und einen Versionsspeicher für die Online-Indexerstellung. Die Versionsspeicher beinhalten Folgendes:

    • Zeilenversionen, die von Datenänderungstransaktionen in einer Datenbank generiert werden, die READ COMMITTED durch Isolation der Zeilenversionsverwaltung oder durch Transaktionen der Momentaufnahmeisolation verwendet.
    • Zeilenversionen, die von Datenänderungstransaktionen für Features wie z. B. die folgenden generiert werden: Online-Indexvorgänge, mehrere aktive Resultsets (MARS) und AFTER-Trigger.

Vorgänge in tempdb werden minimal protokolliert, sodass ein Rollback für Transaktionen ausgeführt werden kann. tempdb wird bei jedem Start von SQL Server neu erstellt, sodass das System immer mit einer bereinigten Kopie der Datenbank startet. Temporäre Tabellen und gespeicherte Prozeduren werden beim Trennen der Verbindung automatisch gelöscht; es sind keine Verbindungen aktiv, wenn das System heruntergefahren wird.

Zwischen einzelnen SQL Server-Sitzungen wird also niemals etwas in tempdb gespeichert. Sicherungs- und Wiederherstellungsvorgänge sind für tempdb nicht zulässig.

Physische Eigenschaften von tempdb in SQL Server

In der folgenden Tabelle sind die anfänglichen Konfigurationswerte der Daten- und Protokolldateien von tempdb in SQL Server aufgelistet. Diese Werte basieren auf den Standardwerten für die model-Datenbank. Die Größe dieser Dateien kann sich in den verschiedenen Editionen von SQL Servergeringfügig unterscheiden.

Datei Logischer Name (logical name) Physischer Name (physical name) Ursprüngliche Größe Dateivergrößerung (file growth)
Primäre Daten tempdev tempdb.mdf 8 Megabytes Automatische Vergrößerung um 64 MB, bis der Speicherplatz auf dem Datenträger erschöpft ist
Sekundäre Datendateien temp# tempdb_mssql_#.ndf 8 Megabytes Automatische Vergrößerung um 64 MB, bis der Speicherplatz auf dem Datenträger erschöpft ist
Log templog templog.ldf 8 Megabytes Automatische Vergrößerung um 64 MB, bis der Maximalwert von 2 TB erreicht wird

Die Anzahl von sekundären Datendateien richtet sich nach der Anzahl der (logischen) Prozessoren auf dem Computer. Als allgemeine Regel gilt: Verwenden Sie die Anzahl von Datendateien, die der Anzahl von logischen Prozessoren entspricht, falls die Anzahl von logischen Prozessoren acht oder weniger beträgt. Wenn mehr als acht logische Prozessoren vorhanden sind, verwenden Sie acht Datendateien. Sollte weiterhin ein Konflikt bestehen, erhöhen Sie die Anzahl von Datendateien um ein Vielfaches von vier, bis der Konflikt auf ein akzeptables Ausmaß reduziert ist. Alternativ dazu können Sie auch die Arbeitsauslastung oder den Code ändern.

Der Standardwert für die Anzahl der Datendateien basiert auf den allgemeinen Richtlinien in KB 2154845.

Fragen Sie die Sicht tempdb.sys.database_files ab, um die aktuelle Größe und die Vergrößerungsparameter von tempdb zu überprüfen.

Verschieben Sie die tempdb-Daten- und Protokolldateien in SQL Server

Informationen zum Verschieben der Daten- und Protokolldateien von tempdb finden Sie unter Verschieben von Systemdatenbanken.

Datenbankoptionen für tempdb in SQL Server

In der folgenden Tabelle werden die Standardwerte für alle einzelnen Datenbankoptionen der Datenbank tempdb aufgeführt und, ob die Option geändert werden kann. Zum Anzeigen der aktuellen Einstellungen dieser Optionen verwenden Sie die Katalogsicht sys.databases .

Datenbankoption Standardwert Kann geändert werden.
ALLOW_SNAPSHOT_ISOLATION OFF Ja
ANSI_NULL_DEFAULT OFF Ja
ANSI_NULLS OFF Ja
ANSI_PADDING OFF Ja
ANSI_WARNINGS OFF Ja
ARITHABORT OFF Ja
AUTO_CLOSE OFF Nein
AUTO_CREATE_STATISTICS EIN Ja
AUTO_SHRINK OFF Nein
AUTO_UPDATE_STATISTICS EIN Ja
AUTO_UPDATE_STATISTICS_ASYNC OFF Ja
CHANGE_TRACKING OFF Nein
CONCAT_NULL_YIELDS_NULL OFF Ja
CURSOR_CLOSE_ON_COMMIT OFF Ja
CURSOR_DEFAULT GLOBAL Ja
Datenbankverfügbarkeitsoptionen ONLINE

MULTI_USER

READ_WRITE
Nein

Nein

Nein
DATE_CORRELATION_OPTIMIZATION OFF Ja
DB_CHAINING EIN Nein
ENCRYPTION OFF Nein
MIXED_PAGE_ALLOCATION OFF Nein
NUMERIC_ROUNDABORT OFF Ja
PAGE_VERIFY CHECKSUM für neue Installationen von SQL Server

NONE für Upgrades von SQL Server
Ja
PARAMETERIZATION SIMPLE Ja
QUOTED_IDENTIFIER OFF Ja
READ_COMMITTED_SNAPSHOT OFF Nein
RECOVERY SIMPLE Nein
RECURSIVE_TRIGGERS OFF Ja
Service Broker-Optionen ENABLE_BROKER Ja
TRUSTWORTHY OFF Nein

Eine Beschreibung dieser Datenbankoptionen finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

„tempdb“ in Azure SQL

Das Verhalten von tempdb in Azure SQL Database unterscheidet sich vom Verhalten SQL Server, Azure SQL Managed Instance und SQL Server auf Azure-VMs.

„tempdb“ in SQL-Datenbank

Einzel- und Pooldatenbanken in Azure SQL-Datenbank unterstützen globale temporäre Tabellen und globale temporäre gespeicherte Prozeduren, die auf die Datenbankebene beschränkt sind und in tempdb gespeichert werden. Globale temporäre Tabellen und globale temporäre gespeicherte Prozeduren sind für alle Benutzersitzungen innerhalb derselben Datenbank freigegeben. Benutzersitzungen von anderen Datenbanken können nicht auf globale temporäre Tabellen zugreifen. Weitere Informationen finden Sie unter Database scoped global temporary tables (Azure SQL Database) (Globale temporäre Tabellen auf Datenbankebene (Azure SQL-Datenbank)).

Für Einzel- und Pooldatenbanken in Azure SQL-Datenbank sind von allen Systemdatenbanken nur die Datenbank und tempdb die master Datenbank zugänglich. Weitere Informationen finden Sie unter Was ist ein logischer Server in Azure?

Weitere Informationen zu tempdb Größen in Azure SQL-Datenbank finden Sie unter:

„tempdb“ in SQL Managed Instance

Azure SQL Managed Instance unterstützt temporäre Objekte auf dieselbe Weise wie SQL Server, wobei alle globalen temporären Tabellen und globalen temporären gespeicherten Prozeduren für alle Benutzersitzungen innerhalb derselben verwalteten Instanz zugänglich sind. Ebenso ist der Zugriff auf alle Systemdatenbanken möglich.

Weitere Informationen zu tempdb Größen in Azure SQL Managed Instance finden Sie unter Ressourcenlimits.

Beschränkungen

Die folgenden Vorgänge können in der tempdb-Datenbank nicht ausgeführt werden:

  • Hinzufügen von Dateigruppen.
  • Sichern und Wiederherstellen der Datenbank.
  • Ändern der Sortierung. Die Standardsortierung entspricht der Serversortierung.
  • Ändern des Datenbankbesitzers tempdb befindet sich im Besitz von sa.
  • Erstellen einer Datenbankmomentaufnahme.
  • Löschen der Datenbank.
  • Löschen des guest -Benutzers aus der Datenbank.
  • Aktivieren von Change Data Capture.
  • Teilnehmen an der Datenbankspiegelung.
  • Entfernen der primären Dateigruppe, der primären Datendatei oder der Protokolldatei.
  • Umbenennen der Datenbank oder der primären Dateigruppe.
  • Ausführen von DBCC CHECKALLOC.
  • Ausführen von DBCC CHECKCATALOG.
  • Festlegen der Datenbank auf OFFLINE.
  • Festlegen der Datenbank oder primären Dateigruppe auf READ_ONLY.

Berechtigungen

Jeder Benutzer kann temporäre Objekte in tempdb erstellen. Benutzer haben nur Zugriff auf ihre eigenen Objekte, es sei denn, ihnen wurden zusätzliche Berechtigungen zugewiesen. Es ist möglich, die Berechtigung zum Herstellen einer Verbindung mit tempdb zu widerrufen, um einen Benutzer an der Verwendung von tempdb zu hindern. Dies wird jedoch nicht empfohlen, da die Verwendung von tempdb für einige Routinevorgänge erforderlich ist.

Optimieren der tempdb-Leistung in SQL Server

Die Größe und die physische Platzierung der tempdb-Datenbank kann sich auf die Leistung eines Systems auswirken. Ein Beispiel: Wenn eine zu geringe Größe für tempdb definiert wurde, muss bei jedem Neustart der SQL Server-Instanz möglicherweise ein Teil der Systemverarbeitungslast dafür aufgewendet werden, die tempdb-Datenbank automatisch auf den Umfang zu vergrößern, der zum Unterstützen der anfallenden Arbeitsauslastung erforderlich ist.

Verwenden Sie nach Möglichkeit die schnelle Dateiinitialisierung, um die Leistung von Vergrößerungsvorgängen für Datendateien zu verbessern.

Weisen Sie allen tempdb-Dateien im Voraus Speicherplatz zu, indem Sie die Dateigröße auf einen Wert festlegen, der hoch genug ist, um der üblichen Arbeitsauslastung in der Umgebung gerecht zu werden. Durch die Vorabzuordnung wird verhindert, dass tempdb zu häufig vergrößert und die Leistung dadurch beeinträchtigt wird. Für die tempdb-Datenbank sollte die automatische Vergrößerung festgelegt werden, um den Speicherplatz für nicht geplante Ausnahmen zu erhöhen.

Datendateien sollten in jeder Dateigruppe die gleiche Größe aufweisen, da SQL Server einen Algorithmus für das proportionale Auffüllen verwendet, in dem Zuteilungen in Dateien mit mehr freiem Platz bevorzugt werden. Ein Aufteilen von tempdb in mehrere Datendateien gleicher Größe bietet einen hohen Grad an paralleler Effizienz in Vorgängen, in denen tempdb verwendet wird.

Legen Sie das Inkrement des Dateiwachstums auf eine angemessene Größe fest, und legen Sie es in allen Datendateien auf das gleiche Inkrement fest, um zu verhindern, dass die tempdb Datenbankdateien um einen zu kleinen Wert wachsen. Wenn die Vergrößerung im Vergleich zur Menge der in tempdb geschriebenen Daten zu gering ist, muss tempdb möglicherweise ständig vergrößert werden. Dies beeinträchtigt die Leistung.

Verwenden Sie die folgende Abfrage, um die aktuelle Größe und die Vergrößerungsparameter von tempdb zu überprüfen:

 SELECT FileName = df.name,
   current_file_size_MB = df.size*1.0/128,
   max_size = CASE df.max_size
     WHEN 0 THEN 'Autogrowth is off.'
     WHEN -1 THEN 'Autogrowth is on.'
     ELSE 'Log file grows to a maximum size of 2 TB.'
   END,
   growth_value =
     CASE
       WHEN df.growth = 0 THEN df.growth
       WHEN df.growth > 0 AND df.is_percent_growth = 0 THEN df.growth*1.0/128.0
       WHEN df.growth > 0 AND df.is_percent_growth = 1 THEN df.growth
     END,
   growth_increment_unit =
     CASE
       WHEN df.growth = 0 THEN 'Size is fixed.'
       WHEN df.growth > 0 AND df.is_percent_growth = 0  THEN 'Growth value is MB.'
       WHEN df.growth > 0 AND df.is_percent_growth = 1  THEN 'Growth value is a percentage.'
     END
FROM tempdb.sys.database_files AS df;
GO

Platzieren Sie die tempdb-Datenbank auf einem schnellen E/A-Subsystem. Verwenden Sie Datenträgerstriping, wenn viele Datenträger direkt angeschlossen sind. Einzelne oder Gruppen von tempdb-Datendateien müssen nicht unbedingt auf verschiedenen Datenträgern oder Spindeln gespeichert sein, es sei denn, Sie stellen außerdem E/A-Engpässe fest.

Platzieren Sie die tempdb-Datenbank nicht auf denselben Datenträgern, die auch von Benutzerdatenbanken genutzt werden.

Leistungsverbesserungen in tempdb für SQL Server

Ab SQL Server 2016 (13.x) wird die Leistung von tempdb auf folgende Weise weiter optimiert:

  • Temporäre Tabellen und Tabellenvariablen werden zwischengespeichert. Das Zwischenspeichern ermöglicht eine sehr schnelle Ausführung der Vorgänge zum Löschen und Erstellen der temporären Objekte. Zudem reduziert es Konflikte bei Seitenzuordnung und Metadaten.
  • Das Latchprotokoll für Zuordnungsseiten wurde verbessert, um die Anzahl der verwendeten UP-Latches (Updatelatches) zu verringern.
  • Der Protokollierungsaufwand für tempdb wurde verringert, um die E/A-Bandbreite des Datenträgers für die tempdb-Protokolldatei zu reduzieren.
  • Das Setup fügt während der Installation einer neuen Instanz mehrere tempdb-Datendateien hinzu. Für diese Aufgabe können Sie die neue Eingabesteuerung der Benutzeroberfläche im Abschnitt Datenbank-Engine-Konfiguration und den Befehlszeilenparameter /SQLTEMPDBFILECOUNT verwenden. Standardmäßig fügt das Setup die Anzahl von tempdb-Datendateien hinzu, die der Anzahl von logischen Prozessoren entspricht, höchstens jedoch acht.
  • Wenn mehrere tempdb-Datendateien vorhanden sind, werden alle Dateien je nach Wachstumseinstellungen automatisch gleichzeitig und um denselben Wert vergrößert. Ablaufverfolgungsflag 1117 ist nicht mehr erforderlich.
  • Alle Zuordnungen in tempdb verwenden einheitliche Erweiterungen. Ablaufverfolgungsflag 1118 ist nicht mehr erforderlich.
  • Für die primäre Dateigruppe ist die Eigenschaft AUTOGROW_ALL_FILES aktiviert. Diese kann nicht geändert werden.

Weitere Informationen zu Leistungsverbesserungen in tempdb finden Sie im Blogbeitrag TEMPDB - Files and Trace Flags and Updates, Oh My! (TEMPDB – Dateien und Ablaufverfolgungsflags und Updates, o je!).

Speicheroptimierte tempdb-Metadaten

Bislang stellten Metadatenkonflikte in tempdb einen Engpass für die Skalierbarkeit vieler Workloads dar, die in SQL Server ausgeführt wurden. SQL Server 2019 (15.x) wird ein neues Feature eingeführt, das Teil der In-Memory-Datenbankfunktionsfamilie ist: speicheroptimierte tempdb Metadaten.

Dieses Feature beseitigt diesen Engpass effektiv und ermöglicht eine neue Skalierbarkeit für tempdbWorkloads mit hohem Umfang. In SQL Server 2019 (15.x) können die Systemtabellen, die an der Verwaltung von Metadaten temporärer Tabellen beteiligt sind, in nicht dauerhafte speicheroptimierte Tabellen ohne Latches verschoben werden.

Hinweis

Derzeit ist das speicheroptimierte tempdb Metadatenfeature nicht in Azure SQL-Datenbank oder Azure SQL Managed Instance verfügbar.

Sehen Sie sich dieses siebenminütige Video an, um eine Übersicht darüber zu finden, wie und wann speicheroptimierte tempdb Metadaten verwendet werden:

Konfigurieren und Verwenden speicheroptimierter tempdb-Metadaten

Mit dem folgenden Skript können Sie dieses neue Feature aktivieren:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON;

Damit diese Konfigurationsänderung wirksam wird, muss der Dienst neu gestartet werden.

Mit dem folgenden T-SQL-Befehl können Sie überprüfen, ob tempdb speicheroptimiert ist:

SELECT SERVERPROPERTY('IsTempdbMetadataMemoryOptimized');

Wenn nach dem Aktivieren von speicheroptimierten tempdb-Metadaten der Server aus irgendeinem Grund nicht startet, können Sie das Feature umgehen, indem Sie die SQL Server-Instanz über die Startoption -f in der Minimalkonfiguration starten. Dann können Sie das Feature deaktivieren und SQL Server im normalen Modus neu starten.

Zum Schutz des Servers vor potenziellen Bedingungen mit nicht genügendem Arbeitsspeicher können Sie tempdb an einen Ressourcenpool binden. Dies erfolgt über den Befehl ALTER SERVER anstelle der Schritte, die Sie normalerweise befolgen, um einen Ressourcenpool an eine Datenbank zu binden.

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON (RESOURCE_POOL = 'pool_name');

Diese Änderung erfordert auch einen Neustart, um wirksam zu werden, selbst wenn speicheroptimierte tempdb Metadaten bereits aktiviert sind.

Einschränkungen von speicheroptimierten tempdb-Metadaten

  • Das Ein- und Ausschalten dieser Funktion ist nicht dynamisch. Aufgrund der systeminternen Änderungen, die an der Struktur von tempdb vorgenommen werden müssen, ist ein Neustart erforderlich, um das Feature zu aktivieren oder zu deaktivieren.

  • Eine einzelne Transaktion darf nicht auf speicheroptimierte Tabellen in mehreren Datenbanken zugreifen. Bei Transaktionen, an denen eine speicheroptimierte Tabelle in einer Benutzerdatenbank beteiligt ist, ist ein Zugriff auf tempdb-Systemsichten nicht innerhalb derselben Transaktion möglich. Wenn Sie versuchen, in derselben Transaktion auf tempdb-Systemsichten zuzugreifen, wird die folgende Fehlermeldung angezeigt:

    A user transaction that accesses memory optimized tables or natively compiled modules cannot access more than one user database or databases model and msdb, and it cannot write to master.
    

    Beispiel:

    BEGIN TRAN;
    
    SELECT *
    FROM tempdb.sys.tables;  -----> Creates a user in-memory OLTP transaction in tempdb
    
    INSERT INTO <user database>.<schema>.<mem-optimized table>
    VALUES (1); ----> Tries to create a user in-memory OLTP transaction in the user database but will fail
    
    COMMIT TRAN;
    
  • Abfragen in speicheroptimierten Tabellen unterstützen keine Sperr- und Isolationshinweise, daher werden diese Hinweise bei Abfragen in speicheroptimierten tempdb-Katalogsichten nicht berücksichtigt. Ebenso wie bei anderen Systemkatalogsichten in SQL Server erfolgen alle Transaktionen für Systemsichten in READ COMMITTED-Isolation (bzw. in diesem Fall in READ COMMITTED SNAPSHOT-Isolation).

  • Columnstore-Indizes können in temporären Tabellen nicht erstellt werden, wenn speicheroptimierte tempdb-Metadaten aktiviert sind.

  • Aufgrund der Einschränkung für Columnstore-Indizes wird die Verwendung der gespeicherten Systemprozedur sp_estimate_data_compression_savings mit dem Datenkomprimierungsparameter COLUMNSTORE oder COLUMNSTORE_ARCHIVE nicht unterstützt, wenn speicheroptimierte tempdb-Metadaten aktiviert sind.

  • Eine gespeicherte Systemprozedur ist verfügbar, um manuell dazu zu veranlassen, dass die In-Memory-Engine Arbeitsspeicher freigibt, der sich auf gelöschte Zeilen von In-Memory-Daten bezieht, die für die Garbage Collection geeignet sind. Dies kann bei der Problembehandlung für bestimmte speicheroptimierte tempdb-Metadaten (HkTempDB) helfen, die nicht genügend Arbeitsspeicher aufweisen. Weitere Informationen finden Sie unter sys.sp_xtp_force_gc (Transact-SQL).

Hinweis

Diese Einschränkungen kommen nur beim Verweisen auf tempdb-Systemsichten zum Tragen. Sie können bei Bedarf eine temporäre Tabelle in derselben Transaktion erstellen, wenn Sie auf eine speicheroptimierte Tabelle in einer Benutzerdatenbank zugreifen.

Kapazitätsplanung für tempdb in SQL Server

Das Festlegen der angemessenen Größe von tempdb in einer SQL Server-Produktionsumgebung hängt von vielen Faktoren ab. Wie bereits erläutert, gehören die vorhandene Arbeitsauslastung und die verwendeten SQL Server-Features zu diesen Faktoren. Es wird empfohlen, die vorhandene Workload durch Ausführen folgender Aufgaben in einer SQL Server-Testumgebung zu analysieren:

  • Legen Sie die automatische Vergrößerung für tempdb fest.
  • Führen Sie einzelne Abfragen oder Ablaufverfolgungsdateien für die Arbeitsauslastung aus, und überwachen Sie die Speicherplatzbelegung von tempdb.
  • Führen Sie Indexverwaltungsvorgänge aus – z. B. die Neuerstellung von Indizes –, und überwachen Sie den tempdb-Speicherplatz.
  • Verwenden Sie die Werte der Speicherplatzbelegung aus den vorherigen Schritten, um die gesamte Arbeitsauslastung zu prognostizieren. Passen Sie diesen Wert an die veranschlagten gleichzeitigen Aktivitäten an, und legen Sie dann die Größe von tempdb entsprechend fest.

Überwachen der Tempdb-Verwendung

Unzureichender Speicherplatz in tempdb kann erhebliche Unterbrechungen in der SQL Server-Produktionsumgebung verursachen. Dieses Problem kann auch dazu führen, dass Anwendungen Vorgänge nicht abschließen können. Mit der dynamischen Verwaltungssicht sys.dm_db_file_space_usage können Sie den in den tempdb-Dateien verwendeten Speicherplatz überwachen:

 -- Determining the amount of free space in tempdb
SELECT SUM(unallocated_extent_page_count) AS [free pages],
  (SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]
FROM tempdb.sys.dm_db_file_space_usage;

-- Determining the amount of space used by the version store
SELECT SUM(version_store_reserved_page_count) AS [version store pages used],
  (SUM(version_store_reserved_page_count)*1.0/128) AS [version store space in MB]
FROM tempdb.sys.dm_db_file_space_usage;

-- Determining the amount of space used by internal objects
SELECT SUM(internal_object_reserved_page_count) AS [internal object pages used],
  (SUM(internal_object_reserved_page_count)*1.0/128) AS [internal object space in MB]
FROM tempdb.sys.dm_db_file_space_usage;

-- Determining the amount of space used by user objects
SELECT SUM(user_object_reserved_page_count) AS [user object pages used],
  (SUM(user_object_reserved_page_count)*1.0/128) AS [user object space in MB]
FROM tempdb.sys.dm_db_file_space_usage;

Darüber hinaus können Sie die dynamischen Verwaltungssichten sys.dm_db_session_space_usage und sys.dm_db_task_space_usage verwenden, um die Seitenzuordnung und die Zuordnungsaufhebung in tempdb auf der Sitzungs- oder Taskebene zu überwachen. Mit diesen Sichten können Sie umfangreiche Abfragen, temporäre Tabellen oder Tabellenvariablen identifizieren, die sehr viel Speicherplatz in tempdb belegen. Sie können auch verschiedene Leistungsindikatoren verwenden, um den in tempdb verfügbaren freien Speicherplatz sowie die Ressourcen zu überwachen, die tempdb verwenden.

-- Obtaining the space consumed by internal objects in all currently running tasks in each session
SELECT session_id,
  SUM(internal_objects_alloc_page_count) AS task_internal_objects_alloc_page_count,
  SUM(internal_objects_dealloc_page_count) AS task_internal_objects_dealloc_page_count
FROM sys.dm_db_task_space_usage
GROUP BY session_id;

-- Obtaining the space consumed by internal objects in the current session for both running and completed tasks
SELECT R2.session_id,
  R1.internal_objects_alloc_page_count
  + SUM(R2.internal_objects_alloc_page_count) AS session_internal_objects_alloc_page_count,
  R1.internal_objects_dealloc_page_count
  + SUM(R2.internal_objects_dealloc_page_count) AS session_internal_objects_dealloc_page_count
FROM sys.dm_db_session_space_usage AS R1
INNER JOIN sys.dm_db_task_space_usage AS R2 ON R1.session_id = R2.session_id
GROUP BY R2.session_id, R1.internal_objects_alloc_page_count,
  R1.internal_objects_dealloc_page_count;

Nächste Schritte