I was wondering what would happen if there would be an application crash,
system crash, or power failure while SQLite is updating the file header?

Did I miss an explanation somewhere?

----------
From: David Raymond <david.raym...@tomtom.com>
Date: Tue, Feb 6, 2018 at 12:04 PM
Subject: Re: [sqlite] Header corruption
To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>


Things stored in the first 25 bytes include page size, WAL status, and the
file change counter. So at least part of the header there gets changed with
every committed write transaction.

http://www.sqlite.org/fileformat2.html


-----Original Message-----
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Deon Brewis
Sent: Tuesday, February 06, 2018 11:57 AM
To: SQLite mailing list
Subject: [sqlite] Header corruption

I’m trying to track down SQLITE corruptions that seems to corrupt our
databases in a consistent way. (Running on 3.20.1).

This isn’t related to a crash or hardware failure. The app is running and
reading and writing to the database fine, and then suddenly we start
getting a SQLITE_NOTADB errors. The first error we got was on trying to
execute a ‘BEGIN TRANSACTION’, and everything thereafter started failing.

When our database headers are fine, I see this:
00000000h: 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 ; SQLite format
3.
00000010h: 10 00 02 02 00 40 20 20 00 00 10 9B 00 01 34 42 ; .....@
...›..4B

On corruption #1, I see this:
00000000h: 15 03 01 00 20 01 91 21 85 44 17 2C ED BE 21 FA ; ....
.‘!…D.,í¾!ú
00000010h: 9E 74 E7 EA 9A 0A 15 2C 99 B0 B7 3B C6 F0 35 FB ;
žtçêš..,™°·;Æð5û

On corruption #2, I see this:
00000000h: 15 03 01 00 20 0F 1E CB B1 FF 9C 1E D0 D6 BB 22 ; ....
..˱ÿœ.ÐÖ»"
00000010h: 15 64 D3 F4 DD 38 FB DF A3 E0 47 B8 D7 F6 21 BC ;
.dÓôÝ8ûߣàG¸×ö!¼


This bit pattern of “15 03 01 00” for the first 4 characters where it
should be “SQLi” is a bit too much of a coincidence to ignore or write off
as disk error.

The rest of the header and file after the first 25-ish bytes or so, seem
fine. It’s just these first 25  bytes that gets corrupted. If I restore
Offsets 0 to Offsets 27 out of a “working” database, I get a usable file.

Under what circumstances would SQLITE even attempt to re-write the header
string?

- Deon

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to