Question

I am using a SQLite database to store values from a data logger. The data logger will eventually fills up all the available hard drive space on the computer. I’m looking for a way to remove the last 25% of the logs from the database once it reaches a certain limit.

Using the following code:

$ret = Query( 'SELECT id as last FROM data ORDER BY id desc LIMIT 1 ;' ); 
$last_id = $ret[0]['last'] ; 
$ret = Query( 'SELECT count( * ) as total FROM data' );
$start_id = $last_id - $ret[0]['total'] * 0.75 ; 
Query( 'DELETE FROM data WHERE id < '. round( $start_id, 0 ) );

A journal file gets created next to the database that fills up the remaining space on the drive until the script fails.

How/Can I stop this journal file from being created?
Anyway to combined all three SQL queries in to one statement?

Answer 1

If the journal is the sole cause of the issue, you could try having SQLite do its journaling in memory, or just turn it off.

From the docs:

PRAGMA journal_mode;
PRAGMA database.journal_mode;
PRAGMA journal_mode = DELETE | TRUNCATE | PERSIST | MEMORY | OFF
PRAGMA database.journal_mode = DELETE | TRUNCATE | PERSIST | MEMORY | OFF

This pragma queries or sets the journal mode for databases associated with the current database connection.

The first two forms of this pragma query the current journaling mode. In the first form, the default journal_mode is returned. The default journaling mode is the mode used by databases added to the connection by subsequent ATTACH statements. The second form returns the current journaling mode for a specific database.

The last two forms change the journaling mode. The 4th form changes the journaling mode for a specific database connection. Use “main” for the main database (the database that was opened by the original sqlite3_open(), sqlite3_open16(), or sqlite3_open_v2() interface call) and use “temp” for database that holds TEMP tables. The 3rd form changes the journaling mode on all databases and it changes the default journaling mode that will be used for new databases added by subsequent ATTACH commands. The new journal mode is returned. If the journal mode could not be changed, the original journal mode is returned.

The DELETE journaling mode is the normal behavior. In the DELETE mode, the rollback journal is deleted at the conclusion of each transaction. Indeed, the delete operation is the action that causes the transaction to commit. (See the documented titled Atomic Commit In SQLite for additional detail.)

The TRUNCATE journaling mode commits transactions by truncating the rollback journal to zero-length instead of deleting it. On many systems, truncating a file is much faster than deleting the file since the containing directory does not need to be changed.

The PERSIST journaling mode prevents the rollback journal from being deleted at the end of each transaction. Instead, the header of the journal is overwritten with zeros. This will prevent other database connections from rolling the journal back. The PERSIST journaling mode is useful as an optimization on platforms where deleting or truncating a file is much more expensive than overwriting the first block of a file with zeros.

The MEMORY journaling mode stores the rollback journal in volatile RAM. This saves disk I/O but at the expense of database safety and integrity. If the application using SQLite crashes in the middle of a transaction when the MEMORY journaling mode is set, then the database file will very likely go corrupt.

The OFF journaling mode disables the rollback journal completely. No rollback journal is ever created and hence there is never a rollback journal to delete. The OFF journaling mode disables the atomic commit and rollback capabilities of SQLite. The ROLLBACK command no longer works; it behaves in an undefined way. Applications must avoid using the ROLLBACK command when the journal mode is OFF. If the application crashes in the middle of a transaction when the OFF journaling mode is set, then the database file will very likely go corrupt.

Note that the journal_mode for an in-memory database is either MEMORY or OFF and can not be changed to a different value. An attempt to change the journal_mode of an in-memory database to any setting other than MEMORY or OFF is ignored. Note also that the journal_mode cannot be changed while a transaction is active.