On 13 April 2011 15:33, Simon Slavin <slav...@bigfraud.org> wrote: > > On 13 Apr 2011, at 12:14pm, James Green wrote: > >> sync=full does not work well for our app (no transactions). Far too slow. > > If you're not syncing, then section 3.2 of the page Richard probably > indicates what's causing your corruption.
Without a reset or power loss? This is the bit that's causing concern. > So for a while, leave that PRAGMA alone, accept that you're going to get slow > running, and see whether this makes the corruption go away. If it does then > you can tackle the speed problem separately without worrying about data > corruption. This is the approach we will be rolling out. More specifically we'll be trying synchronous=normal. It will likely take a few days before we can roll this out and evaluate. > It might be worth trying to figure out whether your storage system can handle > the speed you're expecting. If you have multiple threads all trying to write > at the same time can your hard disk handle that much data at that speed ? If > not, then that's probably why you're finding the use of 'sync' to be too slow. We can say that SQL Server survives just fine. We are not hitting the disk but hundreds of megabytes of changes. One of our operations has the following times: sync=FULL: 3m 43s sync=OFF: 10.5s We're talking approximately 2,000 rows consisting of 3x 32-char string columns and 2x booleans. This is without WAL mode and without transactions. Worth noting is that we only have one test environment in which we can get corruption to occur and we cannot get it to happen at will. All other test systems operate fine without corruption with sync=OFF. James _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
