我们有两个使用在Ubuntu 12.04服务器上托管的SQLite3（gem sqlite3 1.3.7）的Rails 3.2应用程序。操作系统和数据库都在同一磁盘上（AWS EBS）
一个人从未遇到过sqlite3的问题。另一个去年到目前为止有2 complete lock-out（需要重启）和一个file corruption。
这两个应用的用户负载很小。我们不太明白这是怎么发生的。唯一的区别是第二个rails应用程序有一个第三方程序上传大量的记录到应用程序，我们怀疑这个第三方软件对sqlite3做了一些坏事。
我们没有关于如何设计和开发第三方软件的信息。它的唯一用途是将一些电子表格数据上传到应用程序，应用程序将它们保存到表格中。
我们的问题是sqlite3是否容易被第三方软件破坏？
如果是，如何防止sqlite3被第三方软件破坏和/或为第三方软件开发人员指定其他要求以防止软件破坏SQLite。
答案 0 :(得分：3)
the SQLite FAQ on corruption的第2.3节似乎是一个可能的候选人：
2.3使用不同锁定协议的两个进程
SQLite在unix平台上使用的默认锁定机制是 POSIX咨询锁定，但还有其他选择。选择一个 替代sqlite3_vfs使用sqlite3_open_v2（）接口[...]。
...
与同一数据库文件的所有连接使用相同的锁定协议非常重要。 [...] ...... 可能导致数据库损坏。。
在你的位置，我会在strace或（更详细）ltrace下运行神秘的“第三方软件”，看看它是如何做的，如果我无法得到信息我需要详细的SQLite日志记录。
另一种可能性是第三方应用程序“聪明”并且做某种复制，更新，交换技巧，这对普通文件是安全的，但保证了开放数据库的严重损坏。同样，您将能够在strace输出中看到这一点。准备好在分析strace输出的过程中做一些学习，但是......
如果第三方应用嵌入了不同的SQLite数据库引擎版本，您可能会看到由不匹配的版本引起的问题。请参阅3.7.0与3.6.x的FAQ条目：
7.5 Corruption following alternating writes from 3.6 and 3.7.
答案 1 :(得分：2)
官方网站有一个非常comprehensive的列表，列出了sqlite db可能被破坏的方法。以下是该页面的简要列表：
很容易想象一个写得不好的程序会导致1。