I'm using MapProxy to create an MBTiles database. After I delete files with mapproxy-seed.exe --cleanup, I know that I will need to run vacuum, as in this mailing list answer:
when you remove larger blocks of tiles, you need to do a
vacuum
and this other mailing list answer:
SQLite does not "release memory” if you remove records, but it will re-use the space.
See https://sqlite.org/lang_vacuum.html but be aware that your cache in unavailable during VACUUM.
But how do I actually run the VACUUM process? Do I need to connect to my .mbtiles database with an external manager, or can I run this from the command line somehow?
VACUUM is an SQL statement that you run like any other SQL statement.
If you don't have any other mechanism, download the tools package and run:
sqlite3.exe MyMBTiles.db vacuum
Related
As far as I can tell both commands create a clone of the db in SQLite format in the end, so why are there two commands to do this?
.backup uses the SQLite Backup API to create a clone atomically, even if the database is in use.
.clone copies the database by just running SQL commands. As far as I can tell, no transactions are done on the source database when doing the clone, so it has a chance of getting partially updated data mid way through the clone.
I have a website solution that uses on SQLite database for each tenant account. Without going into much depth about why we chose this solution, we chose it due to SQLite support on distributed/offline systems.
All databases are manipulated using the same PHP file structure. I wish to update the database version iteratively for all accounts so that they are all at the same version number.
I have a script that loops over each, and can use either PHP(Yii) or the shell to execute queries.
I would like to wrap the manipulation to each database in a transaction. It appears as though DDL commands may already be auto-commit in nature.
Question: How to accomplish a SQLite DB upgrade which, if it fails, will report a failure? Using that report, I could prompt the system to re-attempt or report an error to an admin. Ideally, I would like to wrap the whole upgrade in a transaction to prevent inconsistencies, but I'm fairly certain that this is not possible.
One thought I had was to backup the database temporarily during upgrade, and delete it on success.
As CL stated in the comments, DDL is fully transactional in SQLite. So, for each database in our system, we wrap it in a transaction, and it executes atomically. We leverage the application to ensure that all databases upgrade successfully if any fail during upgrade.
I'd like to know how the .dump command affects other applications connected to the same database. I'd like to know this for the following journal modes:
DELETE (the default mode)
WAL (write-ahead-logging)
From reading other posts on this forum .backup uses the online backup API of SQLite. It would be great to have this confirmed as well.
Thanks in advance!
The .dump command reads the contents of the database normally, just as if you would do a bunch of SELECT queries inside a transaction.
This means that when not using WAL, other connections cannot write as long as the dump is running.
Very basic question, having a hard time finding an explanation online.
I have a file code.sql that can be run on two different databases, a.db3 and b.db3. I used sqlite a.db3 to open the database in sqlite3. How do I run code.sql on it?
Use the .read code.sql command, or call sqlite3 with the file as input: sqlite3 a.db3 < code.sql.
I am guessing that you are trying to use the sqlite3 command line tool that you can dowload from the sqlite.org website.
I recomend that you use, instead, sqlitestudio http://sqlitestudio.one.pl
This has a feature to execute SQL from a file on a database:
Use DB Browser for SQLite is a high quality, visual, open source tool to create, design, and edit database files compatible with SQLite.
You can download the DB Browser at SQLite https://sqlitebrowser.org/
I have a script that was reading data from a sqlite3 database and while this script was running I made a copy of the database cp mydatabase mydatabase.bak. Will this affect either the script that was reading from the db or the copy of the db? I had a look at the sqlite documentation here [0] but I didn't put a lock on the db as per the instructions.
[0] http://www.sqlite.org/backup.html
Copying the file should be analogous to another application reading the database, so it shouldn't be a problem. Multiple applications can safely read the database file at the same time (per the SQLite FAQ).
As another point, consider that you can read from a database even if the database and its directory both lack write permissions. Since in that scenario there's no way for the reading application to be modifying the database file or creating a temp file that needs to be incorporated into it, there's no way for any of a number of simultaneously reading applications to affect what any of the others see.