当我输入这个查询: 删除邮件中id = 71的所有邮件

SQLite返回以下错误:

SQL error: database is locked

我如何解锁数据库,以便这个查询将工作?


当前回答

在我的例子中,我也得到了这个错误。

我已经检查了其他进程,可能是锁定数据库的原因,如(SQLite管理器,连接到我的数据库的其他程序)。但是没有其他程序连接到它,它只是同一个应用程序中保持连接的另一个活动SQLConnection。

在建立新的SQLConnection和新命令之前,尝试检查您以前的活动SQLConnection,它可能仍然被连接(首先断开它)。

其他回答

根据我的经验,此错误是由以下原因引起的:您打开了多个连接。

例如:

1个或多个sqlitebrowser (GUI) 一个或多个电子线 rails线程

我不确定SQLITE3如何处理多线程/请求的细节,但当我关闭sqlitebrowser和电子线程时,rails运行良好,不会再阻塞了。

删除-journal文件听起来是个糟糕的主意。它允许sqlite在崩溃后将数据库回滚到一致的状态。如果在数据库处于不一致状态时删除它,则会留下一个损坏的数据库。引用sqlite站点的一个页面:

If a crash or power loss does occur and a hot journal is left on the disk, it is essential that the original database file and the hot journal remain on disk with their original names until the database file is opened by another SQLite process and rolled back. [...] We suspect that a common failure mode for SQLite recovery happens like this: A power failure occurs. After power is restored, a well-meaning user or system administrator begins looking around on the disk for damage. They see their database file named "important.data". This file is perhaps familiar to them. But after the crash, there is also a hot journal named "important.data-journal". The user then deletes the hot journal, thinking that they are helping to cleanup the system. We know of no way to prevent this other than user education.

The rollback is supposed to happen automatically the next time the database is opened, but it will fail if the process can't lock the database. As others have said, one possible reason for this is that another process currently has it open. Another possibility is a stale NFS lock, if the database is on an NFS volume. In that case, a workaround is to replace the database file with a fresh copy that isn't locked on the NFS server (mv database.db original.db; cp original.db database.db). Note that the sqlite FAQ recommends caution regarding concurrent access to databases on NFS volumes, because of buggy implementations of NFS file locking.

我无法解释为什么删除一个-journal文件会让你锁定一个数据库,而你以前不能。这是可复制的吗?

顺便说一下,-journal文件的存在并不一定意味着发生了崩溃或有要回滚的更改。Sqlite有几种不同的日志模式,在PERSIST或TRUNCATE模式下,它始终保留-journal文件,并更改内容以指示是否有要回滚的部分事务。

正如Seun Osewa所说,有时僵尸进程会占用终端中的锁,即使您认为这是不可能的。您的脚本运行,崩溃,然后返回到提示,但是在某个库调用生成了一个僵尸进程,并且该进程拥有锁。

关闭您所在的终端(在OSX上)可能有用。重启就可以了。你可以寻找(例如)没有做任何事情的“python”进程,并杀死它们。

SQLite db文件只是文件,所以第一步是确保它不是只读的。另一件要做的事情是确保在DB打开时没有某种GUI SQLite DB查看器。可以在另一个shell中打开DB,也可以在代码中打开DB。通常情况下,如果不同的线程或应用程序(如SQLite Database Browser)打开了数据库以便写入,则会看到这种情况。

从您之前的评论中,您说存在一个-journal文件。

这可能意味着您已经打开和(EXCLUSIVE?)事务,还没有提交数据。是你的程序或者其他进程留下了-journal吗?

重新启动sqlite进程将查看日志文件,清除任何未提交的操作并删除-journal文件。