Viele DBMS zeichnen bei einer Datenänderung die Änderung in einem Protokoll (Journal, Log) auf und schreiben dieses Protokoll vor der eigentlichen Datenbank auf nichtflüchtigen Speicher (WAL: Write-Ahead Logging). Was ist der Hauptgrund für dieses Vorgehen?

Antwort: A. Selbst nach einem Ausfall können anhand des Protokolls festgeschriebene Änderungen wiederholt und nicht festgeschriebene rückgängig gemacht werden, sodass ein korrekter Zustand wiederhergestellt wird

Aus Leistungsgründen werden Datenbankseiten in Puffern im Arbeitsspeicher geändert und erst einige Zeit später auf den Speicher geschrieben. Im Moment eines Ausfalls kann der Speicher daher eine Mischung aus festgeschriebenen Änderungen, die noch nicht geschrieben wurden, und nicht festgeschriebenen Änderungen, die bereits geschrieben wurden, enthalten. Werden die Werte vor und nach jeder Änderung im Protokoll festgehalten und wird das Protokoll vor der eigentlichen Datenbank geschrieben, lassen sich nach einem Ausfall anhand des Protokolls festgeschriebene Änderungen wiederholen (Rollforward, REDO) und nicht festgeschriebene rückgängig machen (Rollback, UNDO), sodass ein korrekter Zustand wiederhergestellt wird. Ein Commit kann als abgeschlossen gelten, sobald der Commit-Eintrag der Transaktion im Protokoll steht; die Datenbankseiten müssen also nicht jedes Mal sofort geschrieben werden, was die Leistung erhält. Dieser Mechanismus trägt die Atomarität und Dauerhaftigkeit der ACID-Eigenschaften.