Recovery dauert? Nicht mehr lange.

Wenn SQL Server abstürzt, läuft beim Start der Recovery-Prozess.
Uncommitted TX zurückrollen, committed TX nachziehen.
Dafür braucht’s: das Transaktionslog.

Früher: Cache leer → alles neu laden.
Heute: Persistent Log Buffers (PLB).
Seit SQL Server 2019 (nur auf entsprechender Hardware).
Ab 2022 weiter verbessert.

Was ist ein Persistent Log Buffer?

Ein spezieller Bereich im Speicher – meist NVDIMM oder PMem.
Schreibvorgänge ins Transaktionslog landen erst dort.
Und sind trotzdem „persistiert“ – also über Neustarts hinweg verfügbar.

Vorteil: Keine Wartezeit auf langsame SSDs oder Storage-Latenz.
Und: Beim Recovery nach Crash spart SQL Server I/O.

Wie aktiviert man PLB?

Du brauchst:

• SQL Server Enterprise Edition
• Kompatible PMem-Hardware (z. B. Intel Optane)
• Betriebssystem-Unterstützung (Windows Server 2019 oder neuer)
• Registry-Eintrag oder SQL-Konfiguration

-- prüfen, ob PLB aktiv ist
SELECT * 
FROM sys.dm_os_sys_info
WHERE memory_node_id = 0;

Registry-Beispiel:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQLServer]
"EnablePersistentLogBuffer"=dword:00000001

Danach Neustart des SQL Server-Dienstes.

Was bringt es konkret?

Tests zeigen: Recovery-Zeit halbiert bis gedrittelt.
Je nach Workload.

Typischer Workload-Vorteil

-- INSERT-starker Prozess
BEGIN TRAN;
INSERT INTO dbo.logdaten(ts, wert) VALUES (SYSDATETIME(), 123.45);
COMMIT;

Ohne PLB: Jeder Commit = I/O → Flaschenhals bei vielen kleinen TX
Mit PLB: TX landet sofort im persistierten RAM → I/O entkoppelt

PLB mit In-Memory OLTP kombinieren

Ideal:

• viel INSERT / UPDATE
• Echtzeitanforderung
• kein SSD-Flaschenhals erlaubt

Kombination:

-- Beispiel In-Memory Tabelle
CREATE TABLE dbo.sensordaten (
    id BIGINT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
    wert FLOAT,
    ts DATETIME2
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

PLB reduziert Recovery-Zeit auch für solche Objekte.
Weil das Transaktionslog eben schneller zur Verfügung steht.

Was PLB nicht ist

• Kein Ersatz für Backup
• Keine Alternative zu HA/DR
• Kein Zaubertrick bei kaputter Hardware
• Nicht aktiv auf Azure SQL oder SQL MI

Du brauchst physisch erreichbaren persistenten Speicher.

Monitoring: Wie voll ist der Buffer?

SELECT 
    log_flush_waits,
    num_log_flush_buffers
FROM sys.dm_os_log_buffer_stats;

Nur verfügbar, wenn PLB aktiv ist.
Sonst kommt nix zurück.

Mein Fazit

Persistent Log Buffers beschleunigen das, was Du hoffentlich nie brauchst: Recovery.
Aber wenn’s knallt, willst Du nicht 40 Minuten auf deine OLTP-Datenbank warten.

Wenn Du viel Transaktionslast hast und kritische Recovery-Zeiten vermeiden willst, lohnt sich PLB.