Benutzer:C rall/Artikelentwurf2
Das sogenannte write ahead logging (WAL) ist ein Verfahren der Datenbanktechnologie, das zur Gewährleistung der Atomarität und Dauerhaftigkeit von Transaktionen beiträgt. Es besagt, dass Modifikationen vor dem eigentlichen Schreiben (dem Einbringen in die Datenbank) protokolliert werden müssen.[1]
Funktionsweise[Bearbeiten | Quelltext bearbeiten]
Durch das WAL-Prinzip wird ein sogenanntes „update-in-place“ ermöglicht, d. h. die alte Version eines Datensatzes wird durch die neue Version an gleicher Stelle überschrieben.[2] Das hat vor allem den Vorteil, dass Indexstrukturen bei Änderungsoperationen nicht mit aktualisiert werden müssen, weil die geänderten Datensätze immer noch an der gleichen Stelle zu finden sind. Die vorherige Protokollierung einer Änderung ist erforderlich, um im Fehlerfall die Wiederholbarkeit der Änderung sicherstellen zu können. Durch dieses Verfahren ist es nicht notwendig, Daten-Seiten bei jedem Transaktionsabschluss auf die Festplatte zu schreiben. Im Falle eines Absturzes kann die Datenbank mithilfe des Protokolls wiederhergestellt werden, indem alle Änderungen, die nicht auf die Daten-Seiten angewendet wurden, aus dem Protokoll neu durchgeführt werden (Roll-Forward-Recovery oder REDO).[3] WAL führt zu einer erheblichen Reduzierung der Festplattenschreibvorgänge, da nur die Protokolldatei auf die Festplatte geschrieben werden muss, um eine Transaktion zu bestätigen, anstatt jede durch die Transaktion geänderte Datenbankdatei. Dies ist besonders vorteilhaft für Server, die viele kleine Transaktionen verarbeiten und auf verschiedene Bereiche des Datenspeichers zugreifen, da die Protokolldatei sequentiell geschrieben wird.[4]
Einzelnachweise[Bearbeiten | Quelltext bearbeiten]
- ↑ 30.3. Write-Ahead Logging (WAL). In: Documentation, PostgreSQL 16. The PostgreSQL Global Development Group, 2024, abgerufen am 30. Januar 2024 (englisch): „Write-Ahead Logging (WAL) is a standard method for ensuring data integrity. [...] Briefly, WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after WAL records describing the changes have been flushed to permanent storage.“
- ↑ Russell Sears, UC Berkeley; Eric Brewer, UC Berkeley: Segment-Based Recovery: Write-ahead logging revisited. (PDF) VLDB Endowment, 28. August 2009, abgerufen am 30. Januar 2024 (englisch): „Write-ahead logging algorithms from the database literature were traditionally optimized for small, concurrent, update-in-place transactions, and later extended for larger objects such as images and other file types.“
- ↑ 30.3. Write-Ahead Logging (WAL). In: Documentation, PostgreSQL 16. The PostgreSQL Global Development Group, 2024, abgerufen am 30. Januar 2024 (englisch): „If we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages can be redone from the log records. (This is roll-forward recovery, also known as REDO.)“
- ↑ 30.3. Write-Ahead Logging (WAL). In: Documentation, PostgreSQL 16. The PostgreSQL Global Development Group, 2024, abgerufen am 30. Januar 2024 (englisch): „Using WAL results in a significantly reduced number of disk writes, because only the log file needs to be flushed to disk to guarantee that a transaction is committed, rather than every data file changed by the transaction. The log file is written sequentially, and so the cost of syncing the log is much less than the cost of flushing the data pages. This is especially true for servers handling many small transactions touching different parts of the data store.“