Home / Emergency Rescue / Database Locked / Broken
Lesson 3 of 5

Database Locked / Broken

Concept

SQLite uses a file lock for writes. If a process crashes mid-write, the lock can stick. WAL mode (which your apps use) helps, but sometimes you need to manually check the database integrity.
Emergency commands
# Check if database is healthy
sqlite3 data/mesh.db 'PRAGMA integrity_check;'
# Should say: ok

# Check WAL mode is on
sqlite3 data/mesh.db 'PRAGMA journal_mode;'
# Should say: wal

# Force WAL checkpoint (flush pending writes)
sqlite3 data/mesh.db 'PRAGMA wal_checkpoint(TRUNCATE);'

# If db is corrupted — make a clean copy
sqlite3 data/mesh.db '.dump' | sqlite3 data/mesh_recovered.db

# Check for lock files (shouldn't exist when no process is running)
ls -la data/mesh.db*
# mesh.db, mesh.db-wal, mesh.db-shm are normal with WAL mode

What's happening

WAL mode keeps a separate write-ahead log (.db-wal). The .db-shm file is shared memory for coordinating readers. Both are normal. If the db is locked and no process is running, delete the -wal and -shm files — SQLite will recreate them.

Quick Check — 3 questions

1. What does PRAGMA integrity_check do?

2. What are .db-wal and .db-shm files?

3. How do you recover a corrupted SQLite database?