HI Michael,

Thanks for the reply. Wont keeping things in memory lead to chances of
db getting corrupt especially in cases of power failure or device reboots.
I am not sure but since Sqlite is now used so frequently in embedded devices
and most devices use flash memories how are these situations mitigated.
Are there are papers/best practices available that can help. It seems to be
that if we try to reduce NAND writes by doing things in memory we lose on
reliability and the way to increase reliability is to do frequent writes. Is
that
a correct understanding?

Thanks
Pankaj

On Mon, Aug 30, 2010 at 5:15 PM, Black, Michael (IS) <michael.bla...@ngc.com
> wrote:

> Can you keep your database in-memory and just copy it to your flash
> periodically?  That would give you the most control and minimize the # of
> writes as much as you want.  It's good you recognize that you'll burn your
> flash out quickly with what you're doing now.
>
> There's also the -DSQLITE_TEMP_STORE option which keeps temporary files
> in-memory.
> You probably want SQLITE_TEMP_STORE=3 during compilation.
>
> ** This function returns true if main-memory should be used instead of
> ** a temporary file for transient pager files and statement journals.
> ** The value returned depends on the value of db->temp_store (runtime
> ** parameter) and the compile time value of SQLITE_TEMP_STORE. The
> ** following table describes the relationship between these two values
> ** and this functions return value.
> **
> **   SQLITE_TEMP_STORE     db->temp_store     Location of temporary
> database
> **   -----------------     --------------
> ------------------------------
> **   0                     any                file      (return 0)
> **   1                     1                  file      (return 0)
> **   1                     2                  memory    (return 1)
> **   1                     0                  file      (return 0)
> **   2                     1                  file      (return 0)
> **   2                     2                  memory    (return 1)
> **   2                     0                  memory    (return 1)
> **   3                     any                memory    (return 1)
>
> Michael D. Black
> Senior Scientist
> Advanced Analytics Directorate
> Northrop Grumman Information Systems
>
>
> ________________________________
>
> From: sqlite-users-boun...@sqlite.org on behalf of Pankaj Chawla
> Sent: Mon 8/30/2010 5:29 AM
> To: sqlite-users@sqlite.org
> Subject: EXTERNAL:[sqlite] Sqlite on NAND flash devices...
>
>
>
> Hi
>
> I have a Sqlite db on an embedded device on which there are
> inserts happening at a rate of 1 insert every 3 seconds. That
> being the case if Sqlite does file close/sync every 3 seconds
> it is going to wear off the NAND in no time. I tried to instead
> put 2 mins worth of inserts inside a transaction/commit block so
> that now data only gets committed every 2 mins. What I observe
> though is that now a journal file gets created during the time
> transaction/commit block is active and I would assume now all
> my 3 second updates are going into the journal file. If that is true it
> means I am still writing to the NAND every 3 seconds through the
> journal file even though the main DB is only getting synced
> with the journal every 2 mins.
>
> Is this understanding correct? If yes, is there a way to actually
> reduce the number of writes happening to the NAND flash such
> that I can save it from quick wear out? If no, how is the writes
> to the main DB different from the writes to the journal?
>
> Thanks
> Pankaj
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to