Write-Ahead Logging (ou WAL, pour « écriture de journaux en amont ») est une méthode courante pour garantir l'intégrité des données. Une description détaillée peut être trouvée dans la plupart des livres sur le traitement transactionnel, sinon tous. En résumé, le concept central du WAL est de ne modifier les fichiers de données (donc les tables et les index) qu'après que les changements ont été journalisés, c'est-à-dire qu'après que les enregistrements décrivant ces changements ont été écrits sur du stockage permanent. Si nous suivons cette procédure, nous n'avons pas besoin d'écrire les pages de données vers le disque à chaque validation de transaction car nous savons que, dans l'éventualité d'une défaillance, nous serons capables de récupérer la base de données en utilisant le journal : chaque changement qui n'a pas été appliqué aux pages de données peut être ré-exécuté depuis les enregistrements du journal. (Ceci est une récupération roll-forward, aussi connue sous le nom de REDO).
Comme les journaux de transaction permettent de restaurer le contenu des
fichiers de base de données après un arrêt brutal, un système de
fichiers journalisé n'est pas nécessaire pour stocker avec fiabilité
les fichiers de données ou les journaux de transactions.
En fait, le
surcroît de travail lié à la journalisation peut réduire les performances,
tout spécialement si la journalisation cause l'écriture des
données sur disque.
Heureusement, l'écriture des données lors de la journalisation
peut souvent être désactivée avec une option de montage du système de
fichiers, par exemple data=writeback sur un système de
fichiers Linux ext3. Par contre, les systèmes de fichiers journalisés
accélèrent le redémarrage après un arrêt brutal.
Utiliser les journaux de transaction permet de réduire de façon
significative le nombre d'écritures sur le disque : seul le journal
a besoin d'être écrit sur le disque pour garantir qu'une
transaction a été validée, il n'y a pas besoin d'écrire dans chaque fichier de
données modifié par la transaction. Ce journal est écrit séquentiellement,
ainsi le coût de vidage sur disque du journal est largement moindre
que le coût d'écriture des pages de données.
Ceci est tout spécialement vrai pour
les serveurs gérant beaucoup de petites transactions touchant différentes
parties du stockage de données. De plus, quand le serveur traite beaucoup de
petites transactions en parallèle, un fsync du
journal des transactions peut suffire pour enregistrer plusieurs
transactions.
Les journaux de transaction rendent possible le support de sauvegarde en ligne et de récupération à un moment donné dans le temps, comme décrit dans la Section 25.3. En archivant les journaux de transaction, nous permettons un retour à tout instant couvert par les données disponibles dans les journaux de transaction : nous installons simplement une ancienne sauvegarde physique de la base de données et nous rejouons les journaux de transaction jusqu'au moment désiré. Qui plus est, la sauvegarde physique n'a pas besoin d'être une image instantanée de l'état de la base de données -- si elle a été faite pendant une longue période de temps, alors rejouer les journaux de transaction pour cette période corrigera toute incohérence interne.