Qu'est-ce que le format de fichier DB-JOURNAL ?
Les fichiers avec l'extension .db-journal contiennent les images de pages nécessaires à la récupération d'une base de données SQLite en cas d'échec de transaction. Ce sont des fichiers temporaires créés par SQLite dans le même répertoire que celui où la base de données est stockée. Ils ne devraient pas être visibles une fois la transaction terminée, car SQLite les supprime automatiquement lors d'un COMMIT ou d'un ROLLBACK.
Grâce aux fichiers journaux de rollback de transaction avec l'extension .db-journal, il est possible de garantir l'atomicité des transactions dans la base de données. Une application opérant sur les données de la base qui plante en cours de transaction ne laissera pas d'opérations incomplètes - elles seront rétablies à l'état antérieur au début de la transaction. Un fichier .db-journal est présent sur le disque :
- pendant l'exécution d'une transaction d'écriture (mode journal DELETE, le mode par défaut de SQLite),
- lorsqu'une transaction a été interrompue par un plantage - jusqu'à ce que la connexion suivante ouvre la base de données,
- lorsque la base de données est en mode de verrouillage exclusif (
PRAGMA locking_mode=EXCLUSIVE) - jusqu'à ce qu'il soit désactivé.
SQLite peut utiliser plusieurs fichiers auxiliaires temporaires différents pour assurer la cohérence et la sécurité des opérations de base de données. .db-journal est le journal de rollback classique ; .db-wal et .db-shm remplissent un rôle équivalent dans le mode plus récent WAL (Write-Ahead Log).
Nommage des fichiers .db-journal
Le fichier journal est nommé en ajoutant -journal au nom complet du fichier de base de données. Par exemple, si la base de données est enregistrée sous baza.db, le fichier temporaire sera nommé baza.db-journal et stocké dans le même répertoire. Les fichiers temporaires ne sont normalement pas visibles par les utilisateurs. En cas de plantage ou de coupure de courant, le journal reste dans le répertoire jusqu'à la prochaine ouverture de la base de données - SQLite détecte alors le « hot journal », rejoue les images de pages sauvegardées pour restaurer l'état pré-transactionnel et supprime le journal automatiquement.
Vous ne devez jamais supprimer un fichier .db-journal pendant qu'une transaction d'écriture est en cours, car cela corromprait la base de données. Un fichier .db-journal persistant après une fermeture propre indique presque toujours un plantage antérieur ; SQLite gère la récupération en toute sécurité lors de la prochaine ouverture. En mode WAL (PRAGMA journal_mode=WAL), introduit dans SQLite 3.7.0 (juillet 2010), le fichier .db-journal n'est pas utilisé du tout - un fichier .db-wal prend son rôle. La plupart des bases de données d'applications modernes sont passées au mode WAL pour une meilleure concurrence de lecture.
Sécurité et sûreté
RISQUE : LOWNon exécutable ; données binaires de récupération après plantage. Supprimer un -journal pendant que la base de données est en cours d'écriture corrompra la base de données - c'est le principal risque opérationnel. Les journaux restants après des plantages peuvent être laissés en toute sécurité jusqu'à ce que SQLite les récupère automatiquement. Un -journal peut contenir des données sensibles non validées de la transaction interrompue (écritures partielles de messages, identifiants, etc.) ; traitez-le avec la même confidentialité que la base de données principale. N'ouvrez pas et ne distribuez pas un -journal isolément sans sa base de données parente.
Détails du format
en brefProgrammes qui ouvrent les fichiers DB-JOURNAL
Windows3 apps
DB Browser for SQLite
Open-source Ouvrez la base de données PRINCIPALE (le fichier .db/.sqlite) - SQLite gère automatiquement le -journal. N'ouvrez pas le -journal directement.
SQLite (sqlite3 CLI)
Open-source Exécutez « sqlite3 mydata.db » ; si un journal actif existe, SQLite l'annule automatiquement lors de la connexion, puis supprime le journal.
Notepad++ (text editor - inspection only)
Open-source Peut afficher le contenu binaire du journal pour une inspection forensique ; l'en-tête magique de 8 octets est visible à l'offset 0. Ne pas éditer. 
macOS2 apps
DB Browser for SQLite
Open-source Ouvrez la base de données PRINCIPALE (le fichier .db/.sqlite) - SQLite gère automatiquement le -journal. N'ouvrez pas le -journal directement.
SQLite (sqlite3 CLI)
Open-source Exécutez « sqlite3 mydata.db » ; si un journal actif existe, SQLite l'annule automatiquement lors de la connexion, puis supprime le journal. 
Linux2 apps
SQLite (sqlite3 CLI)
Open-source Exécutez « sqlite3 mydata.db » ; si un journal actif existe, SQLite l'annule automatiquement lors de la connexion, puis supprime le journal.
DB Browser for SQLite
Open-source Ouvrez la base de données PRINCIPALE (le fichier .db/.sqlite) - SQLite gère automatiquement le -journal. N'ouvrez pas le -journal directement. Détails techniques
spécifications approfondies| Type de format | Journal de rollback de transaction temporaire binaire (fichier auxiliaire SQLite) |
| Octets magiques | En-tête de 8 octets : 0xD9 0xD5 0x05 0xF9 0x20 0xA1 0x63 0xD7 (journal actif/persistant) |
| Ordre des octets | Big-endian (champs d'en-tête du journal stockés dans l'ordre des octets réseau) |
| Taille de l'en-tête du journal | 28 octets (champs pour le nombre de pages, nonce aléatoire, taille de secteur, taille de page) |
| Encodage | Binaire - stocke textuellement les images de pages de la base de données SQLite 3 copiées avant modification |
| Somme de contrôle par page | Deux entiers de 32 bits calculés à partir du nonce et des données de la page ; une discordance signale un journal périmé ou incomplet |
| Taille typique du fichier | De 0 octet à des centaines de Mo selon le nombre de pages touchées par la transaction abandonnée |
| Mode journal | Utilisé uniquement en mode journal DELETE (par défaut dans SQLite) ; non créé en mode WAL |
| Convention de nommage | Chemin de la base de données principale avec -journal ajouté (ex: mydata.db → mydata.db-journal) |
| Mécanisme de récupération | SQLite détecte un journal actif lors de l'ouverture de la connexion, rejoue les images de pages pour restaurer l'état pré-transactionnel, puis supprime le journal |
| Remplacement par WAL | Le mode WAL (.db-wal + .db-shm), introduit dans SQLite 3.7.0 (juillet 2010), est préféré pour les charges de travail concurrentes et n'utilise pas le fichier .db-journal |
| Publié | SQLite 1.0, 2000 (rollback journal is the original journaling mechanism) |
| Dernière version | SQLite 3.x current - format unchanged since early SQLite 3; superseded in practice by WAL (-wal) |
| Standard ouvert | Oui · libre de droits |
| Spécification | www.sqlite.org |
Conversions DB-JOURNAL
Q&R de la communauté
posées par les utilisateursPas encore de questions - soyez le premier à poser une question sur les fichiers DB-JOURNAL.
