Lors de la mise à jour des données, de nombreux SGBD enregistrent les modifications dans un journal (log) et écrivent ce journal sur un support de stockage non volatil avant la base de données elle-même (WAL : journalisation à écriture anticipée, write-ahead logging). Quelle est la principale raison de cette approche ?

Réponse : A. Même si une panne survient, le journal permet de rejouer les mises à jour validées et d'annuler celles qui ne l'étaient pas, ce qui restaure un état correct

Pour des raisons de performances, les pages de la base de données sont mises à jour dans des tampons en mémoire et écrites sur le support de stockage un peu plus tard. Au moment d'une panne, le stockage peut donc contenir un mélange de mises à jour validées pas encore écrites et de mises à jour non validées déjà écrites. Si les valeurs avant et après chaque mise à jour sont enregistrées dans un journal et que le journal est écrit avant la base de données elle-même, on peut, après une panne, utiliser le journal pour rejouer les mises à jour validées (rollforward, REDO) et annuler celles qui ne l'étaient pas (rollback, UNDO), ce qui restaure un état correct. Une validation peut être considérée comme terminée dès que l'enregistrement de validation de la transaction est écrit dans le journal ; il n'est donc pas nécessaire d'écrire immédiatement les pages de la base à chaque fois, ce qui préserve les performances. Ce mécanisme sous-tend l'atomicité et la durabilité des propriétés ACID.