ADR für TempDB: schneller Rollback, halber Durchsatz

Der Preis steht woanders. Dieselbe Änderung dauerte sechs- bis siebenmal so lang. Und acht Sitzungen, die laufend kleine temporäre Tabellen anlegen und wieder löschen, schafften mit ADR für TempDB nur noch die Hälfte bis zwei Fünftel der Arbeit. Ob sich der Schalter lohnt, hängt also davon ab, wie Ihre Anwendung TempDB nutzt.

Kurz gesagt

1. Einschalten: ALTER DATABASE tempdb SET ACCELERATED_DATABASE_RECOVERY = ON; Wirksam erst nach einem Neustart der Instanz. Standard ist aus; SQL Server 2022 lehnt den Befehl ab.
2. Gewinn: Der Rollback einer großen Änderung an einer #temp-Tabelle ist sofort fertig, und das TempDB-Log lässt sich trotz offener Transaktion kürzen.
3. Kosten je Änderung: Jede geänderte Zeile bekommt eine Version im Persistent Version Store (PVS) von TempDB. Die Änderung selbst dauerte im Lab sechs- bis siebenmal so lang.
4. Kosten unter Last: Viele kurze Temp-Tabellen verlieren deutlich Durchsatz, im Lab 48 bis 63 Prozent. Microsoft nennt diese Grenze selbst.
5. Zwei Versionsspeicher: TempDB führt dann den PVS für eigene Transaktionen und daneben weiter den klassischen Version Store für Benutzerdatenbanken ohne ADR. Beide brauchen Platz.
6. Nicht betroffen: Tabellenvariablen (sie werden ohnehin nicht zurückgerollt) und Optimized Locking (gilt in TempDB nicht).

Was ADR in TempDB verspricht

In einer Benutzerdatenbank kennen Sie ADR aus der Vertiefung ADR: Zeilenversionen liegen im Persistent Version Store, ein Rollback markiert die Transaktion nur als abgebrochen, und das Log hängt nicht mehr an der längsten offenen Transaktion. Bis SQL Server 2022 galt das nur für Benutzerdatenbanken. TempDB rollte weiter klassisch zurück, Zeile für Zeile, und eine offene Transaktion auf einer temporären Tabelle hielt das TempDB-Log fest.

Microsoft beschreibt für ADR in TempDB genau zwei Vorteile: sofortigen Rollback und aggressives Kürzen des Logs für alle Transaktionen in TempDB, also temporäre Tabellen, Tabellenvariablen und normale Tabellen, die dort angelegt werden. Dazu kommt ein Hinweis, der zählt: zusätzlichen Platz für den PVS in den TempDB-Dateien einplanen.

Einschalten und prüfen

-- ADR für TempDB einschalten (SQL Server 2025)ALTER DATABASE tempdb SET ACCELERATED_DATABASE_RECOVERY = ON;-- wirksam erst nach einem Neustart der Instanz -- nach dem Neustart prüfenSELECT name, is_accelerated_database_recovery_onFROM sys.databasesWHERE database_id = 2;

Vier Dinge sind dabei anders als bei einer Benutzerdatenbank:

• Der Neustart ist Pflicht. Bis dahin ändert sich nichts, weder das Verhalten noch die Anzeige. Im Lab dauerte der Rollback nach dem ALTER und vor dem Neustart weiter 2,5 Sekunden.
• sys.databases zeigt den wirksamen Zustand, nicht den bestellten. Wer ON gesetzt und noch nicht neu gestartet hat, sieht weiter 0. Eine Stelle, an der ein ausstehender Wechsel sichtbar wäre, haben wir nicht gefunden. Ausschalten funktioniert genauso: OFF, dann Neustart.
• Das Errorlog bestätigt es beim Start mit der Zeile [DbId:2] ADR enabled for the database. Andere Hinweise taugen nicht: Die Zeile für database_id = 2 in sys.dm_tran_persistent_version_store_stats gibt es auch ohne ADR, mit 0 KB.
• Keine exklusive Sperre nötig. Die Klausel WITH ROLLBACK IMMEDIATE soll laut Microsoft nicht angegeben werden; SQL Server nahm sie im Lab trotzdem ohne Meldung an.

SQL Server 2022 lehnt denselben Befehl ab, im Original: Msg 12122, Level 16, State 1 – Accelerated Database Recovery cannot be enabled/disabled on system databases.

Was es bringt: Rollback und Log

Im Lab haben wir eine #temp-Tabelle mit 100.000 Zeilen in einer offenen Transaktion dreimal vollständig geändert, dann ein CHECKPOINT ausgeführt und zurückgerollt. Drei Läufe je Build:

Das ist die gleiche Größenordnung wie in einer Benutzerdatenbank mit ADR (dort 0,1 bis 0,3 ms gegenüber rund 2,5 Sekunden). Der Gewinn ist echt, und er betrifft genau die Fälle, die in TempDB wehtun: ein großer Zwischenschritt in einer #temp-Tabelle, der abbricht, oder eine Transaktion, die offen bleibt, während das TempDB-Log wächst. Was ohne ADR dahintersteckt, beschreibt Version Store und Transaktionslog im TempDB-Hub.

Zwei Einschränkungen gehören dazu:

• Die Änderung wird teurer. Jede geänderte Zeile schreibt eine Version in den PVS von TempDB. Im Lab dauerte das dreifache UPDATE sechs- bis siebenmal so lang, länger sogar als dieselbe Änderung in einer Benutzerdatenbank mit ADR (rund 1,9 Sekunden). Die genaue Ursache haben wir nicht untersucht.
• Der PVS bleibt nach dem Rollback stehen. Die 92 MB gab erst der Cleaner frei, der etwa einmal je Minute läuft. Kurzzeitig belegt ein abgebrochener Zwischenschritt also Platz in TempDB.

Tabellenvariablen profitieren nicht. Ihr Rollback war in allen Läufen sofort fertig, mit und ohne ADR. Der Grund ist alt und hat mit ADR nichts zu tun: Tabellenvariablen werden nicht zurückgerollt. In allen 12 Läufen standen nach dem ROLLBACK weiterhin alle 100.000 Zeilen auf dem geänderten Wert.

Zwei Versionsspeicher in TempDB

Mit ADR für TempDB gibt es dort zwei getrennte Speicher für Zeilenversionen:

Benutzerdatenbanken mit ADR legen ihre Versionen wie gehabt im eigenen PVS ab, nicht in TempDB.

Im Lab hielt eine offene SNAPSHOT-Transaktion in einer Benutzerdatenbank ohne ADR 60 Sekunden lang ihre Versionen fest, während eine zweite Sitzung temporäre Tabellen änderte. Beide Speicher wuchsen nebeneinander: der klassische Store auf 11,9 MB, der PVS von TempDB auf 13,6 MB. Kleine Änderungen landeten dabei als Differenz in der Zeile selbst (21 Byte je Zeile), große als eigener Eintrag im PVS.

Zwei Dinge daraus sind für den Betrieb wichtig:

• Eine Snapshot-Transaktion in irgendeiner Datenbank hält auch den PVS von TempDB fest. Nach ihrem Ende fiel er im Lab binnen drei Sekunden auf 0,35 MB. Wer TempDB wachsen sieht, sucht den Halter also nicht nur in TempDB.
• Der Leistungszähler „Version Store Size (KB)“ zählt nur den klassischen Speicher. Ein Monitoring, das sich darauf verlässt, übersieht den PVS von TempDB vollständig.

Was es kostet: viele kurze Temp-Tabellen

Microsoft nennt für ADR in TempDB eine bekannte Grenze: Werden sehr häufig temporäre Tabellen angelegt und gelöscht, kann es zu Latch-Wartezeiten auf einer TempDB-Systemtabelle kommen; die Seite spricht von einer laufenden Untersuchung und einem geplanten Fix. In den Release Notes zu CU9 und CU10 haben wir keinen Fix gefunden.

Wir haben das nachgestellt: acht Sitzungen, die 60 Sekunden lang ununterbrochen eine #temp-Tabelle anlegen, 1.000 Zeilen einfügen, alle ändern und die Tabelle wieder löschen. Einmal als Schleife im Batch, einmal in einer gespeicherten Prozedur, in der SQL Server die temporäre Tabelle zwischenspeichern kann. Drei Läufe je Zelle, vier CPUs, vier TempDB-Datendateien:

Die Sitzungen warteten in beiden Varianten rund drei Viertel ihrer Zeit auf Seitenlatches auf TempDB-Systemtabellen. Ohne ADR war sysschobjs der Schwerpunkt, mit ADR sysrscols; dazu kamen Latch-Wartezeiten der Klasse PVS_ADD_RECORD, die ohne ADR gar nicht auftreten. Die von Microsoft genannte Tabelle sys.sysseobjvalues tauchte in keiner unserer Stichproben auf; ob beides dieselbe Ursache hat, können wir nicht sagen. Allokationsseiten (PFS, GAM, SGAM) waren in keinem Fall der Engpass. Der PVS von TempDB wuchs unter dieser Last auf 110 bis 541 MB, obwohl jede Transaktion sofort bestätigt wurde.

Der Unterschied zwischen CU9 und CU10 ist mit drei Läufen je Zelle kein belastbarer Build-Unterschied. Die Richtung ist es: Auf beiden Builds kostete der Schalter rund die Hälfte des Durchsatzes. Ob speicheroptimierte TempDB-Metadaten das abmildern, haben wir nicht gemessen.

Optimized Locking gilt in TempDB nicht

Optimized Locking lässt sich für TempDB nicht einschalten (Msg 12122 … Optimized Locking cannot be enabled or disabled on system databases.), und Microsoft sagt das auch so. Im Lab sahen die Sperren in einer Sitzung, deren Datenbank Optimized Locking nutzt, so aus:

Lokale temporäre Tabellen sieht ohnehin nur die eigene Sitzung; dort gibt es nichts, wofür Optimized Locking nötig wäre. Bei globalen temporären Tabellen bleibt alles beim Alten.

Lagebild: Ist ADR in TempDB an, und wer hält die Versionen?

Die Abfrage zeigt in drei Ergebnissen den wirksamen Zustand samt Platz und Log von TempDB, die beiden Versionsspeicher nebeneinander und die Sitzungen, die Versionen oder das TempDB-Log festhalten.

Abfrage: Lagebild ADR für TempDB

/* PSG Stack · SQL Server Locking · Abfrage 2   Lagebild: Ist ADR in tempdb an, wie groß sind die beiden Versionsspeicher in tempdb, und wer hält sie fest?    !!! WARNUNG — bitte vor dem Ausführen lesen !!!   - Nur lesend. Die Abfrage ändert keine Daten und keine Einstellung und beendet keine Sitzung.   - Momentaufnahme: Versionsspeicher wachsen und schrumpfen laufend. Ein kleiner Wert heißt nur     „in diesem Augenblick klein“. Nicht in einer Schleife oder im Sekundentakt ausführen.   - Rechte: VIEW SERVER STATE (ab SQL Server 2022 genügt VIEW SERVER PERFORMANCE STATE).   - MAXDOP 1: Jede Teilabfrage läuft seriell und belegt keine weiteren Kerne. So bleibt die     Diagnose klein, auch wenn tempdb gerade unter Druck steht.   - Lauffähig ab SQL Server 2019; ADR in tempdb gibt es erst ab SQL Server 2025.     Geprüft im PSG-Lab auf 2025 CU9 und CU10 sowie 2022 CU27 (08.11.2026).   - Eingeschaltet wird ADR in tempdb mit ALTER DATABASE tempdb SET ACCELERATED_DATABASE_RECOVERY = ON;     wirksam erst nach einem Neustart der Instanz. Diese Abfrage schaltet nichts.    Ergebnisse:     1  Zustand: Schalter, Start der Instanz, Platz und Log von tempdb     2  Die zwei Versionsspeicher in tempdb: PVS (Versionen tempdb-eigener Transaktionen, nur mit        tempdb-ADR) und klassischer Version Store (Versionen aus Benutzerdatenbanken ohne ADR)     3  Wer hält Versionen oder das tempdb-Log fest: älteste Snapshot-/RCSI-Transaktionen und        älteste offene Transaktionen in tempdb (je höchstens 5)*/SET NOCOUNT ON; /* 1 · Zustand   tempdb_adr zeigt den wirksamen Zustand seit dem letzten Start. Ein ALTER DATABASE tempdb … ohne   Neustart ändert die Spalte noch nicht (im PSG-Lab geprüft, in beide Richtungen); das Errorlog meldet   beim Start „[DbId:2] ADR enabled for the database.“ */SELECT CAST(SERVERPROPERTY('ProductVersion') AS nvarchar(20)) AS version,       CASE d.is_accelerated_database_recovery_on WHEN 1 THEN N'an' ELSE N'aus' END AS tempdb_adr,       si.sqlserver_start_time AS instanz_start,       CASE CAST(SERVERPROPERTY('IsTempdbMetadataMemoryOptimized') AS int) WHEN 1 THEN N'an' ELSE N'aus' END AS speicheroptimierte_metadaten,       f.daten_mb, f.frei_mb,       CAST(l.total_log_size_mb AS decimal(12,1)) AS log_mb,       CAST(l.active_log_size_mb AS decimal(12,1)) AS log_aktiv_mb,       l.log_truncation_holdup_reason AS log_wartet_auf,       CASE WHEN CAST(SERVERPROPERTY('ProductMajorVersion') AS int) < 17                THEN N'ADR für tempdb gibt es erst ab SQL Server 2025.'            WHEN d.is_accelerated_database_recovery_on = 1                THEN N'tempdb-ADR an: Rollback in tempdb sofort, PVS in tempdb einplanen (Ergebnis 2).'            ELSE N'tempdb-ADR aus (Standard).'       END AS hinweisFROM sys.databases AS dCROSS JOIN sys.dm_os_sys_info AS siCROSS APPLY sys.dm_db_log_stats(2) AS lCROSS APPLY (SELECT CAST(SUM(total_page_count) / 128.0 AS decimal(12,1)) AS daten_mb,                    CAST(SUM(unallocated_extent_page_count) / 128.0 AS decimal(12,1)) AS frei_mb             FROM tempdb.sys.dm_db_file_space_usage) AS fWHERE d.database_id = 2OPTION (MAXDOP 1); /* 2 · Die zwei Versionsspeicher in tempdb   PVS: persistent_version_store_size_kb zählt nur Versionen außerhalb der Zeile (off-row);        Versionen in der Zeile (in-row) stecken in den Seiten der temporären Tabellen selbst.   klassisch: Seiten des Version Store (sys.dm_db_file_space_usage), aufgeteilt nach Herkunftsdatenbank        (sys.dm_tran_version_store_space_usage). Benutzerdatenbanken mit ADR haben ihren PVS        in der eigenen Datenbank und erscheinen hier nicht. */SELECT N'PVS (tempdb-ADR)' AS versionsspeicher,       CAST(p.persistent_version_store_size_kb / 1024.0 AS decimal(12,1)) AS belegt_mb,       N'Transaktionen in tempdb: #temp, Tabellenvariablen, Tabellen in tempdb' AS gilt_fuer,       p.current_aborted_transaction_count AS abgebrochene_tx,       p.offrow_version_cleaner_end_time AS letzter_cleaner_lauf,       p.pvs_off_row_page_skipped_min_useful_xts AS seiten_uebersprungen_wegen_snapshot,       CAST(NULL AS nvarchar(400)) AS groesste_verursacher,       CASE WHEN (SELECT is_accelerated_database_recovery_on FROM sys.databases WHERE database_id = 2) = 0                THEN N'tempdb-ADR aus: tempdb-eigene Transaktionen legen keine Versionen an'            WHEN p.offrow_version_cleaner_start_time IS NOT NULL AND p.offrow_version_cleaner_end_time IS NULL                THEN N'Cleaner läuft gerade'            ELSE N'' END AS hinweisFROM (SELECT 1 AS x) AS einsLEFT JOIN sys.dm_tran_persistent_version_store_stats AS p ON p.database_id = 2UNION ALLSELECT N'klassisch (Version Store)',       CAST(v.seiten / 128.0 AS decimal(12,1)),       N'Benutzerdatenbanken ohne ADR: RCSI, Snapshot Isolation, Trigger, Online-Index, MARS',       NULL, NULL, NULL,       (SELECT STRING_AGG(CAST(x.eintrag AS nvarchar(400)), N', ')        FROM (SELECT TOP (3) DB_NAME(database_id) + N' ' + CAST(CAST(reserved_space_kb / 1024.0 AS decimal(12,1)) AS nvarchar(20)) + N' MB' AS eintrag              FROM sys.dm_tran_version_store_space_usage              WHERE reserved_space_kb > 0              ORDER BY reserved_space_kb DESC) AS x),       N''FROM (SELECT SUM(version_store_reserved_page_count) AS seiten FROM tempdb.sys.dm_db_file_space_usage) AS vOPTION (MAXDOP 1); /* 3 · Wer hält Versionen oder das tempdb-Log fest (je höchstens 5, älteste zuerst)   Snapshot-/RCSI-Transaktionen halten die Bereinigung beider Versionsspeicher auf, auch über   Datenbankgrenzen hinweg. Offene Transaktionen in tempdb halten ohne tempdb-ADR das tempdb-Log fest. */SELECT h.art, h.session_id, h.seit_sekunden, h.datenbank, h.login_name, h.program_name, h.tempdb_log_mbFROM (SELECT * FROM (SELECT TOP (5) N'Snapshot-/RCSI-Transaktion' AS art, a.session_id, a.elapsed_time_seconds AS seit_sekunden,             DB_NAME(s.database_id) AS datenbank, s.login_name, s.program_name,             CAST(NULL AS decimal(12,1)) AS tempdb_log_mb      FROM sys.dm_tran_active_snapshot_database_transactions AS a      JOIN sys.dm_exec_sessions AS s ON s.session_id = a.session_id      WHERE a.session_id <> @@SPID      ORDER BY a.elapsed_time_seconds DESC) AS snap      UNION ALL      SELECT * FROM (SELECT TOP (5) N'offene Transaktion in tempdb' AS art, st.session_id,             DATEDIFF(SECOND, dt.database_transaction_begin_time, SYSDATETIME()) AS seit_sekunden,             DB_NAME(s.database_id) AS datenbank, s.login_name, s.program_name,             CAST(dt.database_transaction_log_bytes_used / 1048576.0 AS decimal(12,1)) AS tempdb_log_mb      FROM sys.dm_tran_database_transactions AS dt      JOIN sys.dm_tran_session_transactions AS st ON st.transaction_id = dt.transaction_id      JOIN sys.dm_exec_sessions AS s ON s.session_id = st.session_id      WHERE dt.database_id = 2 AND dt.database_transaction_begin_time IS NOT NULL AND st.session_id <> @@SPID      ORDER BY dt.database_transaction_begin_time) AS offen) AS hORDER BY h.seit_sekunden DESCOPTION (MAXDOP 1);

Beispielausgabe

Beispielausgabe aus einem nachgestellten Lab-Lauf (SQL Server 2025 CU10, synthetische Daten, Namen frei gewählt). ADR für TempDB ist an. In der Datenbank Lager (RCSI und Snapshot Isolation, ohne ADR) hält Sitzung 52 seit 31 Sekunden eine SNAPSHOT-Transaktion offen; eine andere Sitzung hat zwei temporäre Tabellen geändert:

1 · Zustand

version     tempdb_adr instanz_start     speicheroptimierte_metadaten daten_mb frei_mb log_mb log_aktiv_mb log_wartet_auf hinweis
----------- ---------- ----------------- ---------------------------- -------- ------- ------ ------------ -------------- ---------------------------------------------------------------------------
17.0.5035.5 an         2026-11-08 14:37  aus                          2048.0   2025.4  1024.0 .1           CHECKPOINT     tempdb-ADR an: Rollback in tempdb sofort, PVS in tempdb einplanen (Ergebnis 2).


2 · Die zwei Versionsspeicher in tempdb

versionsspeicher          belegt_mb gilt_fuer                                                      abgebrochene_tx letzter_cleaner_lauf seiten_uebersprungen_wegen_snapshot groesste_verursacher hinweis
------------------------- --------- -------------------------------------------------------------- --------------- -------------------- ----------------------------------- -------------------- -------
PVS (tempdb-ADR)          13.3      Transaktionen in tempdb: #temp, Tabellenvariablen, Tabellen ... 0               2026-11-08 14:42     0                                   NULL
klassisch (Version Store) 11.6      Benutzerdatenbanken ohne ADR: RCSI, Snapshot Isolation, ...     NULL            NULL                 NULL                                Lager 11.6 MB


3 · Wer hält Versionen oder das tempdb-Log fest

art                        session_id seit_sekunden datenbank login_name program_name tempdb_log_mb
-------------------------- ---------- ------------- --------- ---------- ------------ -------------
Snapshot-/RCSI-Transaktion 52         31            Lager     app_lager  LagerApp     NULL

Beide Speicher sind gleichzeitig belegt: Der PVS hält die Versionen der temporären Tabellen, der klassische Version Store die der Datenbank Lager. Die SNAPSHOT-Transaktion hält beide fest; im Lab fiel der PVS von TempDB erst nach ihrem Ende von 13,3 auf 0,35 MB.

Rechte: VIEW SERVER STATE, ab SQL Server 2022 genügt VIEW SERVER PERFORMANCE STATE. Ohne das Serverrecht bricht die Abfrage mit Fehler 300 ab. Geprüft auf SQL Server 2025 CU9 und CU10 mit ADR für TempDB an und aus sowie auf 2022, dort mit dem Hinweis, dass es die Option erst ab 2025 gibt.

Wann einschalten, wann nicht

Dafür spricht eine Anwendung, die große Zwischenergebnisse in temporären Tabellen bearbeitet und deren Abbrüche oder lange Transaktionen schon einmal das TempDB-Log gefüllt oder Minuten an Rollback gekostet haben. Dagegen spricht eine Anwendung, die sehr viele kurze temporäre Tabellen in hoher Frequenz anlegt und löscht, etwa in häufig aufgerufenen Prozeduren. Dort war der Durchsatzverlust im Lab deutlich größer als jeder Gewinn beim Rollback.

Weil der Schalter einen Neustart braucht, lässt er sich nicht nebenbei ausprobieren. Messen Sie vorher auf einer Testinstanz mit Ihrer Last, planen Sie Platz für den PVS in den TempDB-Dateien ein, und prüfen Sie nach dem Einschalten Errorlog und Lagebild. Ein Monitoring, das nur den Leistungszähler „Version Store Size“ beobachtet, braucht eine zweite Messgröße.

Häufige Fragen

Brauche ich ADR in den Benutzerdatenbanken, um es für TempDB einzuschalten? Nein. Die beiden Schalter sind unabhängig. Benutzerdatenbanken mit ADR legen ihre Versionen im eigenen PVS ab, ohne ADR im klassischen Version Store von TempDB.

Woran sehe ich, ob ein Neustart noch aussteht? Gar nicht direkt. sys.databases zeigt den wirksamen Zustand seit dem letzten Start. Halten Sie den Wechsel deshalb im Änderungsprotokoll fest und prüfen Sie nach dem Neustart Errorlog und sys.databases.

Hilft ADR für TempDB bei Tabellenvariablen? Nein. Ihr Rollback ist immer sofort, weil Tabellenvariablen nicht zurückgerollt werden.

Wirkt Optimized Locking auf temporäre Tabellen? Nein. TempDB unterstützt Optimized Locking nicht.

Wenn TempDB Ihr Engpass ist

Ob ADR für TempDB bei Ihnen Rollback-Zeit spart oder Durchsatz kostet, zeigt eine Messung an Ihrer Last. Im Rahmen der Performance-Analyse messen wir das auf einer Testinstanz und empfehlen, ob und wann sich der Neustart lohnt. Wer TempDB grundsätzlich prüfen lassen will, findet im Health Check den passenden Einstieg; die Grundlagen stehen im TempDB-Hub.

Weitere Locking-Themen