Wat is het DB-JOURNAL-bestandsformaat?
Bestanden met de extensie .db-journal bevatten de paginakopieën die nodig zijn voor het herstel van een SQLite-database in het geval van een mislukte transactie. Dit zijn tijdelijke bestanden die door SQLite worden aangemaakt in dezelfde map waar de database is opgeslagen. Ze zouden niet zichtbaar moeten zijn nadat de transactie is afgerond, aangezien SQLite ze automatisch verwijdert bij een COMMIT of ROLLBACK.
Dankzij de transactie-rollback-journaalbestanden met de extensie .db-journal is het mogelijk om de atomiciteit van transacties in de database te waarborgen. Een applicatie die werkt met databasegegevens en crasht tijdens een transactie, zal geen onvoltooide bewerkingen achterlaten - deze worden teruggezet naar de staat van voordat de transactie begon. Een .db-journal-bestand is aanwezig op de schijf:
- tijdens de uitvoering van een schrijftransactie (DELETE-journaalmodus, de standaardinstelling van SQLite),
- wanneer een transactie werd onderbroken door een crash - totdat de volgende verbinding de database opent,
- wanneer de database in exclusieve vergrendelingsmodus staat (
PRAGMA locking_mode=EXCLUSIVE) - totdat deze wordt uitgeschakeld.
SQLite kan verschillende tijdelijke hulpbestanden gebruiken om de coherentie en veiligheid van databasebewerkingen te garanderen. .db-journal is het klassieke rollback-journaal; .db-wal en .db-shm dienen voor de gelijkwaardige rol in de nieuwere WAL (Write-Ahead Log) modus.
Naamgeving van .db-journal-bestanden
Het journaalbestand krijgt een naam door -journal toe te voegen aan de volledige bestandsnaam van de database. Als de database bijvoorbeeld is opgeslagen als baza.db, krijgt het tijdelijke bestand de naam baza.db-journal en wordt het in dezelfde map opgeslagen. Tijdelijke bestanden zijn normaal gesproken niet zichtbaar voor gebruikers. In het geval van een crash of stroomstoring blijft het journaal in de map staan tot de volgende keer dat de database wordt geopend - SQLite detecteert dan het „hot journal”, zet de opgeslagen paginakopieën terug om de staat van vóór de transactie te herstellen en verwijdert het journaal automatisch.
U mag nooit een .db-journal-bestand verwijderen terwijl een schrijftransactie bezig is, omdat dit de database zal beschadigen. Een hardnekkig .db-journal-bestand na een schone afsluiting duidt bijna altijd op een eerdere crash; SQLite handelt het herstel veilig af bij de volgende opening. In de WAL-modus (PRAGMA journal_mode=WAL), geïntroduceerd in SQLite 3.7.0 (juli 2010), wordt het .db-journal-bestand helemaal niet gebruikt - een .db-wal-bestand neemt die rol over. De meeste moderne applicatiedatabases zijn overgeschakeld naar de WAL-modus voor verbeterde gelijktijdige leesprestaties.
Beveiliging & veiligheid
RISICO: LOWNiet uitvoerbaar; binaire crash-herstelgegevens. Het verwijderen van een -journal terwijl de database wordt beschreven, zal de database beschadigen - dit is het belangrijkste operationele risico. Achtergebleven journaals van crashes kunnen veilig blijven staan totdat SQLite ze automatisch herstelt. Een -journal kan gevoelige, niet-gecommitteerde gegevens bevatten van de onderbroken transactie (gedeeltelijke schrijfacties van berichten, inloggegevens, enz.); behandel deze met dezelfde vertrouwelijkheid als de hoofddatabase. Open of verspreid een -journal niet los van de hoofddatabase.
Formaatdetails
in een notendopProgramma's die DB-JOURNAL-bestanden openen
Technische details
diepe specificaties| Formaattype | Binair tijdelijk transactie-rollback-journaal (SQLite-hulpbestand) |
| Magic bytes | 8-byte header: 0xD9 0xD5 0x05 0xF9 0x20 0xA1 0x63 0xD7 (hot/persistent journal) |
| Byte-volgorde | Big-endian (journaal-headervelden opgeslagen in network byte order) |
| Grootte journaalheader | 28 bytes (paginatelling, random nonce, sectorgrootte, paginagrootte velden) |
| Codering | Binair - slaat letterlijke SQLite 3 database-paginakopieën op die vóór wijziging zijn gekopieerd |
| Checksum per pagina | Twee 32-bits integers berekend op basis van de nonce en paginagegevens; een mismatch duidt op een verouderd of onvolledig journaal |
| Typische bestandsgrootte | 0 bytes tot honderden MB, afhankelijk van hoeveel pagina's de afgebroken transactie heeft beïnvloed |
| Journaalmodus | Alleen gebruikt in DELETE-journaalmodus (standaard van SQLite); wordt niet aangemaakt in WAL-modus |
| Naamgevingsconventie | Pad van de hoofddatabase met -journal erachter (bijv. mydata.db → mydata.db-journal) |
| Herstelmechanisme | SQLite detecteert een hot journal bij het openen van de verbinding, zet paginakopieën terug om de staat van vóór de transactie te herstellen en verwijdert vervolgens het journaal |
| WAL-vervanging | WAL-modus (.db-wal + .db-shm), geïntroduceerd in SQLite 3.7.0 (juli 2010), geniet de voorkeur voor gelijktijdige workloads en gebruikt het .db-journal-bestand niet |
| Uitgebracht | SQLite 1.0, 2000 (rollback journal is the original journaling mechanism) |
| Laatste versie | SQLite 3.x current - format unchanged since early SQLite 3; superseded in practice by WAL (-wal) |
| Open standaard | Ja · royaltyvrij |
| Specificatie | www.sqlite.org |
DB-JOURNAL conversies
Community V&A
gevraagd door gebruikersNog geen vragen - wees de eerste om iets te vragen over DB-JOURNAL-bestanden.