1. database files are overwritten or deleted by other threads
- After the file descriptor is turned off, continue to use this file descriptor to access
- Open file, get file descriptor fd (actually an orthopedic)
- Close File
- Open SQLite file, get file descriptor (also happens to be) FD
- Another thread continues to use FD to write the file
- SQLite file is corrupted
- Perform database backup or restore during a transaction
During a database transaction, the database file includes both the old content and the new content. If you copy this file at this time, the database may be corrupted. It is best to use the SQLite API for backup databases.
- Delete log files
The log file includes the information required by the rollback. After deletion, it is not possible to roll back correctly, which can cause database corruption.
2. File Lock Related
SQLite uses file locks to ensure multi-threaded access. If the file lock mechanism is not normal, it will cause information such as reading and writing the file, causing the database corruption
- File system does not have the correct mechanism to implement file locks
In the network operating system, the more common
- The close () function is not used correctly
In Unix, the Close () function unlocks the file lock for all threads.
For example, a, B threads open the database file, using the SQLite API. At this point, thread C is called sequentially open()
, read()
as well close()
. At this point, all the locks on this file are gone. So A and B are likely to write data to the file at the same time.
- Two processes using different lock protocols (locking protocols)
It is used by default POSIX advisory locking
and can be sqlite3_open_v2()
modified with functions. If not, the database corruption may occur while reading and writing.
- Rename or unlink when a database file is used
Two processes A, B, and a database connection to a database file at the same time. A close the connection, unlink file, create a new database file with the same name, open this database. It's like this. A, b two processes use different databases, but the names are the same. However, the log files are based on the database name to differentiate the database files. Therefore, the database files for both processes will be the same. Causes the database file to be corrupted.
- A file has multiple connections
This means that a database file has multiple names. If A and B use different names to open the same database link, there will be two log files. If thread A crash, B detects that a rollback is required. The log file could not be found and could not be rolled back.
3. Sync failed
In order to ensure database file consistency (consistent), the fsync()
system call is called and the in-memory data is brushed to disk. If the sync operation fails, it causes the database file to become corrupted
- Sync system call inconsistent with document description
USB flash memory often looks like this. For example, when writing big data, the USB LEDs are still on when the function returns to a successful write.
- Disable sync using pragmas
synchronous=OFF
can improve speed, but will result in inconsistent files.
4. Hard drive, flash damage 5. Memory corruption
When wild pointers, memory overflows, and so on, can cause corruption in the in-memory database structure, potentially causing database file corruption.
When memory-mapped I/O occurs, because memory is mapped directly to the disk, if an array is out of bounds, the data in memory is corrupted and the disk file is corrupted
6. Other Operating system issues
- File system crashes # #7. SQLite bug
Possible causes of database corruption