Bij het wijzigen van gegevens leggen veel DBMS'en de wijzigingen vast in een log (journaal) en schrijven ze die log naar niet-vluchtige opslag vóór de database zelf (WAL: write-ahead logging). Wat is de belangrijkste reden voor deze aanpak?

Antwoord: A. Ook na een storing kan met de log het werk van gecommitte wijzigingen opnieuw worden uitgevoerd en kunnen niet-gecommitte wijzigingen ongedaan worden gemaakt, zodat een correcte toestand wordt hersteld

Om prestatieredenen worden databasepagina's in buffers in het geheugen gewijzigd en pas enige tijd later naar de opslag geschreven. Op het moment van een storing kan de opslag daarom een mengeling bevatten van gecommitte wijzigingen die nog niet zijn weggeschreven en niet-gecommitte wijzigingen die al wel zijn weggeschreven. Als van elke wijziging de waarde ervoor en erna in een log wordt vastgelegd en de log vóór de database zelf wordt geschreven, kan na een storing met de log het werk van gecommitte wijzigingen opnieuw worden uitgevoerd (rollforward, REDO) en kunnen niet-gecommitte wijzigingen ongedaan worden gemaakt (rollback, UNDO), zodat een correcte toestand wordt hersteld. Een commit kan als voltooid worden beschouwd zodra het commitrecord van de transactie in de log staat, dus databasepagina's hoeven niet elke keer direct te worden geschreven, wat de prestaties op peil houdt. Dit mechanisme ondersteunt de atomiciteit en duurzaamheid van de ACID-eigenschappen.