ADR: Der Rollback ist sofort fertig. Bezahlt wird später.
Ein ROLLBACK über 100.000 geänderte Zeilen dauert auf SQL Server 2017 bis 2022 ungefähr so lange wie die Änderung selbst: im Lab 2,5 bis 3,0 Sekunden, unter RCSI auf 2017 sogar 7 Sekunden. Mit Accelerated Database Recovery (ADR) kehrt derselbe ROLLBACK nach 0,1 bis 0,2 Millisekunden zurück. Das ist kein Messfehler. ADR rollt nichts zurück. Es markiert die Transaktion als abgebrochen und lässt die alten Zeilenversionen für sich sprechen.
Diese Seite erklärt, wie das geht, was es kostet und was es mit Sperren zu tun hat. Denn ADR ist seit SQL Server 2025 die Voraussetzung für Optimized Locking.
Kurz gesagt
- ADR verlegt die Zeilenversionen aus TempDB in die Datenbank, in den Persistent Version Store (PVS). Sie werden protokolliert und überleben einen Neustart.
- Rollback ist logisch: Die Transaktion wird als abgebrochen markiert, Leser überspringen ihre Versionen, aufgeräumt wird im Hintergrund.
- Recovery nach einem Neustart hängt nicht mehr an der längsten offenen Transaktion. Im Lab 0,22 bis 0,39 Sekunden statt 1,6 bis 2,3 Sekunden, bei Transaktionen von rund 150 MB Log.
- Das Log kann abgeschnitten werden, auch während eine lange Transaktion läuft. Kein
ACTIVE_TRANSACTIONmehr als Wartegrund für diese Transaktion. - Der Preis: Platz für den PVS, mehr Logvolumen, Schreiblast beim Versionieren; in unserem Extremfall war das UPDATE selbst mit ADR drei- bis viermal langsamer.
- Seit 2019 in Enterprise, Standard und Web; seit 2025 Voraussetzung für Optimized Locking.
Was ohne ADR beim Rollback passiert
Jede Änderung schreibt einen Logeintrag. Ein Rollback liest diese Einträge rückwärts und macht jede Änderung einzeln ungeschehen: Zeile für Zeile, Seite für Seite, protokolliert als Kompensation. Deshalb dauert ein Rollback ungefähr so lange wie die Arbeit, die er zurücknimmt, und deshalb hält die Transaktion währenddessen alle ihre Sperren.
Dasselbe gilt nach einem Absturz oder Neustart: Die Recovery spielt das Log ab dem letzten Checkpoint vor (Redo) und rollt alles zurück, was beim Absturz offen war (Undo). Die längste offene Transaktion bestimmt, wie weit zurück gelesen werden muss. Eine einzige vergessene Transaktion mit vielen Änderungen kann so den Wiederanlauf einer ganzen Datenbank um Minuten verzögern. Und solange sie offen ist, darf das Log ab ihrem Beginn nicht wiederverwendet werden: log_reuse_wait_desc = ACTIVE_TRANSACTION. Dieselbe Recovery steckt auch in der Failover-Dauer einer Failover Cluster Instance oder Availability Group; im Lab gemessen zeigt das Teil 2 der Reihe „FCI vs. Availability Groups“.
Im Lab hielt eine offene Transaktion mit drei Updates über 100.000 Zeilen rund 200 bis 240 MB Log fest. Was das Log sonst noch festhalten kann, behandelt Transaktionslog voll.
Was ADR anders macht
ADR baut auf dem Versionsmechanismus auf, den SQL Server seit 2005 für RCSI und Snapshot Isolation hat, mit zwei Änderungen:
- Der Ort. Zeilenversionen liegen nicht mehr in TempDB, sondern im Persistent Version Store in der Benutzerdatenbank. Für kurze Versionen in der Zeile selbst (in-row), sonst in einer eigenen Struktur (off-row). Sie werden protokolliert und überleben einen Neustart.
- Die Folge. Für jede geänderte Zeile ist dauerhaft bekannt, welche Transaktion sie zuletzt geschrieben hat und ob diese noch läuft. Eine abgebrochene Transaktion muss nichts zurückschreiben: Sie wird in einer Abbruchliste geführt, und wer ihre Version liest, nimmt stattdessen die davor. Das ist der Logical Revert. Physisch aufgeräumt wird später, vom Cleaner, der seit SQL Server 2022 mit mehreren Threads arbeitet.
Für Operationen, die sich nicht versionieren lassen, etwa Änderungen an Allokationsstrukturen, führt ADR ein kleines zweites Log (SLOG) im Speicher, das beim Checkpoint persistiert wird. Dadurch bleibt auch bei DDL die Recovery kurz.
Die Sperrsemantik ändert ADR ausdrücklich nicht. Wer mit ADR weniger Blocking erwartet, wird enttäuscht; das ist die Aufgabe von RCSI und Optimized Locking.
Was es im Lab gebracht hat
Dieselbe Transaktion, drei Updates über je 100.000 Zeilen, danach ROLLBACK; vier Versionen, je drei Läufe:
| ohne ADR | mit ADR (2019–2025) | |
|---|---|---|
ROLLBACK | 2,5–3,0 s (2017 unter RCSI 7,0 s) | 0,1–0,2 ms |
| Log bei offener Transaktion | ACTIVE_TRANSACTION, rund 200–240 MB belegt | NOTHING, 2–16 MB belegt |
| Zeilenversionen unter RCSI | TempDB, rund 29 MB je Durchlauf | PVS in der Datenbank, rund 98 MB je Durchlauf, TempDB 0 |
| Crash-Recovery nach hartem Abbruch | 1,6–2,3 s | 0,22–0,39 s |
| das UPDATE selbst | 0,6–1,3 s | 3,1–4,1 s |
Die letzte Zeile ist der Preis. In LAB-10 auf SQL Server 2025 lag der Rollback von 100.000 Zeilen bei 302,94 ms ohne und 0,69 ms mit ADR; auch dort blieb der UPDATE selbst mit ADR nicht schneller. Der Versuch ist ein Extremfall: ein großes UPDATE auf einer kleinen Tabelle, viele Versionen je Seite. Für gemischte Lasten nennt Microsofts Forschungspaper zu ADR 2,4 bis 13,8 Prozent weniger Durchsatz.
Am 08.11.2026 haben wir beide Muster auf SQL Server 2022 CU27 und 2025 CU10 wiederholt, je drei Läufe: Der Rollback der großen Transaktion dauerte ohne ADR 2,48 bis 2,62 Sekunden, mit ADR 0,10 bis 0,24 Millisekunden; der einfache Rollback einer int-Änderung über 100.000 Zeilen 240 bis 253 Millisekunden gegenüber 0,09 bis 0,12 Millisekunden. Zwei Beobachtungen am Rande: Der erste Lauf mit ADR auf einer frisch geladenen Tabelle schrieb 53,9 MB Log statt 10 bis 17 MB danach, weil die erste Änderung die Datensätze vergrößert und Seiten teilt. Und die kleine int-Änderung erzeugte keinen Zuwachs im off-row-PVS: Solche Versionen hält ADR im Datensatz selbst; die 200-Byte-Änderung dagegen rund 92 MB je Transaktion.
Was ADR kostet, und wo Sie es sehen
Platz im PVS. Im Version-Store-Lab lagen für zehn Durchläufe über 100.000 Zeilen 253 MB Versionen im PVS der Datenbank statt 279 MB im TempDB-Version-Store. Der Platz wandert also nur, er verschwindet nicht; er liegt jetzt in der Datenbank, die Sie sichern und wiederherstellen.
Log. Versionen werden protokolliert. Im selben Lab belegte das Transaktionslog 491 MB statt 142 MB.
Seiten. Sobald Zeilen versioniert werden, kommen bis zu 14 Byte Versionsinformation je Zeile hinzu; im Lab hatte die Tabelle mit ADR doppelt so viele Seiten durch Page Splits, und die Schreiber brauchten gut doppelt so lang.
Aufräumen. Der Cleaner läuft periodisch. Solange eine Transaktion die Versionen noch sehen könnte, etwa ein offener Snapshot-Leser, räumt er nichts ab; im Lab übersprang er dabei 32.417 Seiten. Nach dem Ende des Halters verschwanden die Versionen beim nächsten Takt, nach rund einer Minute. Lange oder abgebrochene Transaktionen lassen den PVS also wachsen; sys.dm_tran_persistent_version_store_stats zeigt Größe, Abbruchliste und Cleaner-Stand.
Wer die Versionen gerade festhält, zeigt Abfrage 2 des TempDB-Hubs, Zeilenversionen und Protokoll aller Datenbanken; sie liest ab SQL Server 2019 auch den Persistent Version Store. Eine eigene PVS-Abfrage haben wir hier bewusst nicht angelegt.
Einschalten, prüfen, zurücknehmen
-- ADR einschalten, optional mit eigener Filegroup für den PVSALTER DATABASE [MeineDB] SET ACCELERATED_DATABASE_RECOVERY = ON (PERSISTENT_VERSION_STORE_FILEGROUP = [PVS_FG]); -- PrüfenSELECT name, is_accelerated_database_recovery_onFROM sys.databasesWHERE name = N'MeineDB';- Der Schalter braucht einen Moment ohne andere aktive Verbindungen in der Datenbank; planen Sie ein Wartungsfenster.
- Eine eigene Filegroup für den PVS lohnt sich, wenn Sie den Platz getrennt beobachten oder auf anderen Speicher legen wollen.
- Zurück geht es mit
OFF, aber nur, wenn Optimized Locking aus ist: Sonst meldet SQL Server 2025 Msg 12134 („Optimized Locking is enabled for this database. To disable Accelerated Database Recovery, disable Optimized Locking and try again.“). - SQL Server 2017 kennt die Option nicht (Msg 102, „Incorrect syntax near 'ACCELERATED_DATABASE_RECOVERY'.“).
- Editionen: seit 2019 in Enterprise, Standard und Web.
Wann ADR einschalten
Dafür sprechen lange Transaktionen, deren Rollback oder Recovery Sie schon einmal Minuten gekostet hat, ein Log, das wegen ACTIVE_TRANSACTION wächst, und der Wunsch nach Optimized Locking in SQL Server 2025. Dagegen sprechen ein ohnehin knapper Datenbank- und Logplatz, sehr schreiblastige Tabellen mit kleinen Zeilen, bei denen die 14 Byte und die Versionen ins Gewicht fallen, und Workloads mit vielen lange offenen Snapshot-Lesern, die den Cleaner ausbremsen. In allen Fällen gilt: an Ihrer Last messen, PVS und Log eine Woche beobachten, dann entscheiden.
Häufige Fragen
Macht ADR meine Abfragen schneller? Nein. ADR macht Rollback und Recovery schnell und das Log unabhängig von langen Transaktionen. Lesen und Schreiben werden eher ein wenig teurer.
Braucht ADR RCSI? Nein. ADR versioniert für sich; RCSI und Snapshot Isolation nutzen dann denselben PVS statt TempDB.
Wächst mein PVS unbegrenzt? Nur, solange etwas die Versionen festhält. Finden Sie die offene Transaktion oder den Snapshot-Leser; sys.dm_tran_persistent_version_store_stats zeigt die älteste gehaltene Transaktion.
Hilft ADR in TempDB? Ja, seit SQL Server 2025. Der Rollback einer #temp-Änderung wird sofort fertig, dafür kostet es unter vielen kurzen Temp-Tabellen deutlich Durchsatz; die Messwerte stehen in ADR für TempDB.
Wenn Rollback und Recovery Ihr Problem sind
Ob ADR in Ihrer Umgebung den erwarteten Nutzen bringt und was es an Platz und Log kostet, lässt sich in einer Woche Beobachtung beantworten. Wir machen das im Rahmen der Performance-Analyse oder prüfen im Health Check, welche Ihrer Datenbanken davon profitieren würden.