Thanks Richard. Are there known tools which tell us what data corrupted the db or some way of removing only the corrupted section of the db ? I will definitely look into the wal mode. Are there any test results for disk failure robustness of this mode compared to journal mode.
I also saw some references to corruption being caused when the same db is written to by 3.6 and then being written to by 3.7. Is that true, because we have similar scenario where the db was originally written by 3.4.0 and when we upgraded our software the db was written to by 3.7.7.1. Do you think this scenario could also cause a db corruption. -Mayank -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Hipp Sent: Wednesday, November 06, 2013 11:18 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] sqlite db getting corrupt on power outage scenarios On Wed, Nov 6, 2013 at 2:10 PM, Mayank Kumar (mayankum) <[email protected]>wrote: > Hi Sqlite Users > I am running into a situation where sometimes after the power is > restored my sqlite db running on linux is corrupted. Here is what I > see with > integrity_check:- > > *** in database main *** > Page 895: btreeInitPage() returns error code 11 On tree page 2 cell > 765: Child page depth differs On tree page 2 cell 766: Child page > depth differs > SQLite is suppose to recover automatically from a power loss, rolling back the last transaction, and NOT corrupting the database file. However, in order to do this, SQLite relies on the filesystem behaving as advertised. Corruption such as you describe can result from a broken fsync() implementation or from consumer-grade disk drives that lie about having flushed their track buffers (saying that they have flushed their track buffers to oxide when in fact they have not). Please read more at http://www.sqlite.org/howtocorrupt.html Please note that setting "PRAGMA journal_mode=WAL" makes SQLite more resistent to disk-drive lies. Not immune, but more resistant. You might want to set WAL mode if you have not done so already. -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
