Journal WAL SQLite (-wal)

En mode write-ahead logging (WAL, journalisation anticipée), SQLite n'écrase pas le fichier de base principal lors de la validation d'une transaction. Il ajoute les pages modifiées à un fichier annexe nommé <base>-wal, que les lecteurs consultent en priorité. Périodiquement, un checkpoint recopie ces pages dans la base principale ; par défaut, cela se produit automatiquement lorsque le WAL atteint environ 1 000 pages. Un fichier -shm associé contient un index en mémoire partagée du WAL.

Pour l'enquêteur, trois conséquences en découlent. D'abord, l'activité la plus récente peut n'exister que dans le fichier -wal : la base, le -wal et le -shm doivent toujours être collectés ensemble. Ensuite, le WAL peut contenir plusieurs versions d'une même page, ce qui préserve parfois des enregistrements modifiés ou supprimés depuis dans le fichier principal. Enfin, le simple fait d'ouvrir la base avec un client SQLite ordinaire peut déclencher un checkpoint, et la fermeture de la dernière connexion fusionne et supprime normalement le WAL — ce qui altère la preuve. Travaillez sur des copies et analysez le WAL séparément lorsque les versions antérieures des pages comptent.

Parmi les artefacts Windows qui utilisent SQLite en mode WAL figurent la chronologie Windows (ActivitiesCache.db), la base de notifications (wpndatabase.db) et les profils Firefox parmi les artefacts de navigateur. Le principe rappelle les journaux de transactions des bases ESE et les journaux de transactions du Registre : des données en attente vivent hors du fichier principal jusqu'à leur fusion.