URL filenames are enabled if any of the following are true: The argument to INTO can be a URI filename if URI filenames are enabled. The file named by the INTO clause must not previously exist, or else it must be an empty file, or the VACUUM INTO command will fail with an error. The filename in the INTO clause can be an arbitrary SQL expression that evaluates to a string. On the other hand, the backup API uses fewer CPU cycles and can be executed incrementally. Also, all deleted content is purged from the backup, leaving behind no forensic traces. The advantage of using VACUUM INTO is that the resulting backup database is minimal in size and hence the amount of filesystem I/O may be reduced. The VACUUM command with an INTO clause is an alternative to the backup API for generating backup copies of a live database. The new database will contain the same logical content as the original database, fully vacuumed. If the INTO clause is included, then the original database file is unchanged and a new database is created in the filename given by the argument to the INTO clause. Prior to that, a schema-name added to the VACUUM statement would be silently ignored and the "main" schema would be vacuumed. Attached databases can be vacuumed by appending the appropriate schema-name to the VACUUM statement.Ĭompatibility Warning: The ability to vacuum attached databases was added in version 3.15.0 (). When in write-ahead log mode, only the auto_vacuum support property can be changed using VACUUM.īy default, VACUUM only works only on the main database. However, when not in write-ahead log mode, the page_size and/or auto_vacuum properties of an existing database may be changed by using the page_size and/or pragma auto_vacuum pragmas and then immediately VACUUMing the database. Normally, the database page_size and whether or not the database supports auto_vacuum must be configured before the database file is actually created. Using VACUUM in this way is an alternative to setting PRAGMA secure_delete=ON. Running VACUUM will clean the database of all traces of deleted content, thus preventing an adversary from recovering deleted content. This can allow deleted content to be recovered by a hacker or by forensic analysis. When content is deleted from an SQLite database, the content is not usually erased but rather the space used to hold the content is marked as being available for reuse. In some cases, VACUUM may also reduce the number of partially filled pages in the database, reducing the size of the database file further. Running VACUUM ensures that each table and index is largely stored contiguously within the database file. Running VACUUM to rebuild the database reclaims this space and reduces the size of the database file.įrequent inserts, updates, and deletes can cause the database file to become fragmented - where data for a single table or index is scattered around the database file. This means the database file might be larger than strictly necessary. Unless SQLite is running in "auto_vacuum=FULL" mode, when a large amount of data is deleted from the database file it leaves behind empty space, or "free" database pages. There are several reasons an application might do this: The VACUUM command rebuilds the database file, repacking it into a minimal amount of disk space.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |