On Wed, Feb 23, 2011 at 11:50:05AM +0530, Sudha Venkatareddy scratched on the wall: > Hi All, > > Input:MyDb.db with size 23KB (has lot of empty pages caused due to delete > operation) > > *Expected OutPut: after applying Vacuum command, should be MyDb.db with > reduced file size of 13KB.* > > *Actual output: MyDb.db remains size 23KB(size not changes from original) > and creates temporary file etilqs_Hm4RUi6JPXcMZ17 whose data is same as > MyDb.db but the size is reduced to 13KB*
VACUUM is a two step process. First, the data is copied from the original file to a temp file. This is a high-level copy, where the data is compacted and reordered, and free pages are eliminated. The second step copies the data from the temp file back to the primary file. This is done as a low-level page-by-page copy. It is *not* an OS file copy. By using the page update system already built into SQLite, the copy-back will create a rollback journal and remain transaction-safe for the whole VACUUM process. From the sound of things, the first step is working, but the second step is failing for some reason. My first guess would be that there are permissions issues with creating the rollback file, so the second copy process fails. That's just a guess, however, as there could be a number of other issues. If you can figure out if a rollback file is ever being created, that would help determine if the copy-back is starting, but fails for some reason, or if the copy-back step is failing right from the start. Given the small database size, it might be somewhat hard to figure that out, however-- any rollback is going to be there and gone (or not there at all) very quickly. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
