Just to make sure I understood you correctly, is this what you are suggesting?
* Open file with sqlite app (in my case sqlite3) * execute BEGIN EXCLUSIVE TRANSACTION; * initiate the file copy * COMMIT; after the copy is finished. I tried doing this, but very early into the copy Windows issues the following error: Errror 0x80070021: The process cannot access the file because another process has locked a portion of the file. On Tue, Jul 7, 2009 at 1:03 PM, John Stanton<jo...@viacognis.com> wrote: > You should synchronize your backup (copy). Try surrounding it with an > exclusive transaction. > > Stan Bielski wrote: >> Sorry for the repost, but the original thread was hijacked by another >> list user. This is a serious problem IMHO; it looks like the DB can't >> be backed-up without rendering the machine unusable if a query hits it >> while a copy is in progress. >> >> Hello, >> >> In the course of copying a largish (20 GB) database file while >> accessing it via sqlite3, the machine became very unresponsive. I >> opened task manager and found that the system was using a huge amount >> of virtual memory, causing it to thrash. Per-process memory usage >> looked normal and did not add up to anywhere near system-wide VM >> usage. >> >> I ran into this issue at a customer site and was able to reproduce it >> using a local Windows 2008 installation. I have not installed any >> backup software or a virus scanner. Storage is local disk, SQLite >> version is 3.3.17. >> >> At first I thought that this was a general Windows problem involving a >> process accessing a file that is being copied, but other binaries I >> tested do not cause the same behavior that sqlite3 does. I performed >> the following experiments to try to diagnose the issue. >> >> Case 1: >> >> * I copy a 20 GB sqlite DB using Windows' own copy utility (e.g. via >> explorer). >> * At any point during the copy, I open the file being copied in sqlite3 >> * I exit sqlite3. >> * During the rest of the copy the OS will consume virtual memory >> linear (seemingly identical) to the amount of data copied since the >> process opened the file. >> >> I repeated this experiment using a similarly-sized file created from >> /dev/zero (i.e. an invalid DB) and the results were the same. >> >> Case 2: >> >> * I copy the sqlite DB using Windows' own copy utility (e.g. via explorer). >> * At any point during the copy, I run 'strings' with the file as an argument. >> * I exit strings. >> * The copy does not result in the OS consuming additional virtual memory. >> >> Case 3: >> >> * I open the DB in sqlite3 >> * I let sqlite3 idle and do not input any commands. >> * I copy a sqlite DB using Windows' own copy utility (e.g. via explorer). >> * I continue to let sqlite3 idle and do not input any commands. >> * During the rest of the copy the OS will consume virtual memory >> linear (seemingly identical) to the amount of data copied since the >> process opened the file. >> >> Is there a workaround for this issue? Any assistance or info is appreciated. >> >> Thanks, >> -Stan >> _______________________________________________ >> 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