我们有两个使用 SQLite3 (gem sqlite3 1.3.7) 的 Rails 3.2 应用程序，托管在 Ubuntu 12.04 服务器上。操作系统和数据库都在同一个磁盘上（AWS EBS）
sqlite3从来没有遇到过问题。另一个有 2 个complete lock-out（需要重新启动）和一个file corruption去年到目前为止。
这两个应用程序的用户负载很小。我们不太明白这是怎么发生的。唯一的区别是 2nd rails 应用程序有一个 3rd 方程序将一堆记录上传到应用程序中，我们怀疑这个 3rd 方软件对 sqlite3 做了什么坏事。
我们没有关于第 3 方软件是如何设计和开发的信息。它的唯一用途是将一些电子表格数据上传到应用程序中，然后应用程序将它们保存到表格中。
我们的问题是 sqlite3 是否容易被第三方软件破坏？
如果是，如何防止 sqlite3 被第 3 方软件损坏和/或为第 3 方软件开发人员指定其他要求以防止软件损坏 SQLite。
Section 2.3 of the SQLite FAQ on corruption seems like a likely candidate:
2.3 Two processes using different locking protocols
The default locking mechanism used by SQLite on unix platforms is POSIX advisory locking, but there are other options. By selecting an alternative sqlite3_vfs using the sqlite3_open_v2() interface [...].
...
It is important that all connections to the same database file use the same locking protocol. [...] ... possibly leading to database corruption..
In your position I'd run the mystery "3rd party software" under strace or (more detailed) ltrace to see what it was doing in detail if I couldn't get the info I needed from detailed SQLite logging.
Another possibility is that the 3rd party app is being "clever" and doing some kind of copy, update, swap trick that's safe for normal files but guarantees serious corruption of an open database. Again, you'll be able to see this in strace output. Be prepared to do some learning in the process of analysing the strace output, though...
If the 3rd party app embeds a different SQLite database engine version you might be seeing issues caused by mismatched versions. See in particular the FAQ entry on 3.7.0 vs 3.6.x:
7.5 Corruption following alternating writes from 3.6 and 3.7.
The official site has a pretty comprehensive list of ways that a sqlite db can be corrupted. Here's a brief list from that page:
One can easily imagine that a badly written program can cause 1.