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

SQLite wiki DatabaseIsLocked页面提供了此错误消息的解释。在某种程度上，它指出争用的来源是内部的(对发出错误的进程而言)。本页没有解释的是SQLite如何决定进程中的某些东西持有锁，以及哪些条件会导致误报。

当您试图从同一个数据库连接同时对数据库执行两项不兼容的操作时，就会出现此错误代码。

在v3中引入的有关文件锁定的变化可能对未来的读者有用，可以在这里找到:SQLite版本3中的文件锁定和并发性

我刚刚遇到了类似的情况——我的web应用程序能够从数据库中读取数据，但不能执行任何插入或更新。重启Apache至少暂时解决了这个问题。

不过，如果能找到根本原因就好了。

我发现SQLite中锁的各种状态的文档非常有用。Michael，如果您可以执行读操作，但不能对数据库执行写操作，这意味着某个进程已经获得了数据库上的保留锁，但还没有执行写操作。如果你正在使用SQLite3，有一个叫做PENDING的新锁，不允许更多的进程连接，但现有的连接仍然可以执行读取，所以如果这是问题所在，你应该看看这个锁。

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

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

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

如果一个进程在SQLite DB上有一个锁，并且崩溃了，那么这个DB将永远处于锁定状态。这就是问题所在。并不是其他进程有锁。

我在Mac OS X 10.5.7上从终端会话运行Python脚本时遇到了同样的问题。尽管我已经停止了脚本，并且终端窗口位于命令提示符处，但它在下次运行时仍然会给出这个错误。解决方案是关闭终端窗口，然后再次打开它。我觉得没道理，但奏效了。

删除-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文件，并更改内容以指示是否有要回滚的部分事务。

我的锁是由系统崩溃引起的，而不是由挂起进程引起的。为了解决这个问题，我简单地重命名了文件，然后将其复制回原来的名称和位置。

使用Linux shell将是:

mv mydata.db temp.db
cp temp.db mydata.db

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

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

在选择重新启动选项之前，有必要看看能否找到sqlite数据库的用户。

在Linux上，可以使用fuser:

$ fuser database.db

$ fuser database.db-journal

在我的案例中，我得到了如下的回应:

philip    3556  4700  0 10:24 pts/3    00:00:01 /usr/bin/python manage.py shell

这表明我有另一个使用数据库的pid 3556 (manage.py)的Python程序。

您可以尝试:.timeout 100来设置超时时间。 我不知道在命令行中发生了什么，但在c# .Net中，当我这样做:“UPDATE table-name SET column-name = value;”我得到数据库被锁定，但这个“UPDATE table-name SET column-name = value”它很好。

看起来，当您添加;，sqlite将寻找进一步的命令。

在windows中，您可以尝试这个程序http://www.nirsoft.net/utils/opened_files_view.html，以找出进程正在处理db文件。尝试关闭该程序解锁数据库

在Linux和macOS中，你可以做类似的事情，例如，如果你锁定的文件是development.db:

$ fuser development.db

这个命令将显示哪个进程正在锁定该文件:

> development.db: 5430

只需终止进程……

杀死-9 5430

.．.您的数据库将被解锁。

应该是数据库的内部问题… 对我来说，这是在尝试用“SQLite管理器”浏览数据库后表现出来的… 所以，如果你找不到另一个连接到数据库的进程，你也无法修复它， 试试这个激进的解决方案:

提供导出您的表(您可以在Firefox上使用“SQLite管理器”) 如果迁移改变了数据库方案，请删除上次失败的迁移 重命名“数据库”。sqlite”文件 执行“rake db:migrate”创建一个新的工作数据库 提供给正确的权限数据库表的导入 导入备份的表 编写新的迁移 执行"rake db:migrate"

我刚才在远程服务器上使用存储在NFS挂载上的SQLite数据库时遇到了这个问题。当我使用的远程shell会话在数据库打开时崩溃后，SQLite无法获得锁。

上面建议的恢复方法对我不起作用(包括先移动然后再复制数据库的想法)。但是在将其复制到非nfs系统后，数据库变得可用，数据似乎没有丢失。

我的Linux环境上的lsof命令帮助我弄清楚一个进程挂起并保持文件打开。 终止了这个过程，问题就解决了。

我导致我的sqlite数据库在写入过程中崩溃一个应用程序而被锁定。以下是我如何修复它:

echo ".dump" | sqlite old.db | sqlite new.db

摘自:http://random.kakaopor.hu/how-to-repair-an-sqlite-database

我只是犯了同样的错误。 5分钟后，我发现我没有关闭一个shell巫婆正在使用db。 请关闭它，再试一次;)

我也有同样的问题。显然，回滚函数似乎用与db文件相同但没有最近更改的日志覆盖了db文件。我已经在下面的代码中实现了这一点，从那时起它一直工作得很好，而之前我的代码会因为数据库保持锁定而陷入循环。

希望这能有所帮助

我的python代码

##############
#### Defs ####
##############
def conn_exec( connection , cursor , cmd_str ):
    done        = False
    try_count   = 0.0
    while not done:
        try:
            cursor.execute( cmd_str )
            done = True
        except sqlite.IntegrityError:
            # Ignore this error because it means the item already exists in the database
            done = True
        except Exception, error:
            if try_count%60.0 == 0.0:       # print error every minute
                print "\t" , "Error executing command" , cmd_str
                print "Message:" , error

            if try_count%120.0 == 0.0:      # if waited for 2 miutes, roll back
                print "Forcing Unlock"
                connection.rollback()

            time.sleep(0.05)    
            try_count += 0.05


def conn_comit( connection ):
    done        = False
    try_count   = 0.0
    while not done:
        try:
            connection.commit()
            done = True
        except sqlite.IntegrityError:
            # Ignore this error because it means the item already exists in the database
            done = True
        except Exception, error:
            if try_count%60.0 == 0.0:       # print error every minute
                print "\t" , "Error executing command" , cmd_str
                print "Message:" , error

            if try_count%120.0 == 0.0:      # if waited for 2 miutes, roll back
                print "Forcing Unlock"
                connection.rollback()

            time.sleep(0.05)    
            try_count += 0.05       




##################
#### Run Code ####
##################
connection = sqlite.connect( db_path )
cursor = connection.cursor()
# Create tables if database does not exist
conn_exec( connection , cursor , '''CREATE TABLE IF NOT EXISTS fix (path TEXT PRIMARY KEY);''')
conn_exec( connection , cursor , '''CREATE TABLE IF NOT EXISTS tx (path TEXT PRIMARY KEY);''')
conn_exec( connection , cursor , '''CREATE TABLE IF NOT EXISTS completed (fix DATE, tx DATE);''')
conn_comit( connection )

我在应用程序中有这样的问题，从2个连接访问SQLite -一个是只读的，第二个用于写入和读取。看起来这个只读连接阻止了第二个连接的写入。最后，需要在使用后立即完成或至少重置准备好的语句。直到准备语句被打开，导致数据库写入被阻塞。

别忘了打电话:

sqlite_reset(xxx);

or

sqlite_finalize(xxx);

如果文件位于远程文件夹(如共享文件夹)中，则可能引发此错误。我将数据库更改为本地目录，它工作得很好。

获得此异常的一个常见原因是，当您试图执行写操作时，仍然为读操作保留资源。例如，如果你从一个表中选择，然后尝试更新你所选择的东西，而不是先关闭你的ResultSet。

如果你想删除一个“database is locked”错误，请按照以下步骤执行:

将数据库文件复制到其他位置。 用复制的数据库替换数据库。这将解除对访问数据库文件的所有进程的引用。

这个环节解决了问题。:当Sqlite给出:数据库锁定错误 它解决了我的问题也许对你有用。

并且可以使用开始事务和结束事务来避免将来数据库被锁定。

我在使用Delphi和LiteDAC组件时得到了这个错误。 事实证明，它只发生在运行我的应用程序从Delphi IDE，如果连接属性设置为True的SQLite连接组件(在这种情况下TLiteConnection)。

由于某种原因，数据库被锁定了。以下是我的解决方法。

我将sqlite文件下载到我的系统(FTP) 删除在线sqlite文件 将文件上传到主机提供商

现在可以正常工作了。

有些函数，比如INDEX'ing，可能会花费很长时间——而且在运行时它会锁定整个数据库。在这种情况下，它甚至可能不使用日志文件!

因此，最好/唯一的方法来检查您的数据库是否被锁定，因为一个进程正在积极地写入它(因此你应该让它独自呆着，直到它完成它的操作)是md5(或md5sum在某些系统)文件两次。 如果你得到一个不同的校验和，数据库正在被写入，你真的真的真的不想杀死这个进程，因为如果你这样做，你很容易得到一个损坏的表/数据库。

我要重申一下，因为这很重要——解决方案不是找到锁程序并杀死它——而是找出数据库是否有一个很好的写锁，然后从那里开始。有时候正确的解决方法就是喝杯咖啡休息一下。

The only way to create this locked-but-not-being-written-to situation is if your program runs BEGIN EXCLUSIVE, because it wanted to do some table alterations or something, then for whatever reason never sends an END afterwards, and the process never terminates. All three conditions being met is highly unlikely in any properly-written code, and as such 99 times out of 100 when someone wants to kill -9 their locking process, the locking process is actually locking your database for a good reason. Programmers don't typically add the BEGIN EXCLUSIVE condition unless they really need to, because it prevents concurrency and increases user complaints. SQLite itself only adds it when it really needs to (like when indexing).

Finally, the 'locked' status does not exist INSIDE the file as several answers have stated - it resides in the Operating System's kernel. The process which ran BEGIN EXCLUSIVE has requested from the OS a lock be placed on the file. Even if your exclusive process has crashed, your OS will be able to figure out if it should maintain the file lock or not!! It is not possible to end up with a database which is locked but no process is actively locking it!! When it comes to seeing which process is locking the file, it's typically better to use lsof rather than fuser (this is a good demonstration of why: https://unix.stackexchange.com/questions/94316/fuser-vs-lsof-to-check-files-in-use). Alternatively if you have DTrace (OSX) you can use iosnoop on the file.

我在多线程应用程序中也有“数据库被锁定”错误，这似乎是SQLITE_BUSY结果代码，我通过将sqlite3_busy_timeout设置为适当的长度(如30000)来解决这个问题。

(顺便说一句，对于一个7年前的问题，居然没有人发现这一点，这真奇怪!SQLite真的是一个奇特而神奇的项目…)

我添加了“池=true”连接字符串，它工作。

一个老问题，有很多答案，这里是我最近遵循的步骤，阅读上面的答案，但在我的情况下，问题是由于cifs资源共享。这个病例以前没有报道过，希望能帮助到一些人。

检查java代码中没有任何连接是打开的。 使用lsof检查是否有其他进程正在使用您的SQLite db文件。 检查正在运行的jvm进程的用户所有者对该文件具有r/w权限。 尝试在连接开口上强制锁定模式 final SQLiteConfig config = new SQLiteConfig(); config.setReadOnly(假); config.setLockingMode (LockingMode.NORMAL); connection = DriverManager。getConnection (url, config.toProperties ());

如果您在NFS共享文件夹上使用SQLite db文件，请检查SQLite faq的这一点，并检查您的挂载配置选项，以确保避免锁定，如下所述:

//myserver /mymount cifs username=*****,password=*****,iocharset=utf8,sec=ntlm,file,nolock,file_mode=0700,dir_mode=0700,uid=0500,gid=0500 0 0

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

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

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

这是因为该数据库上正在运行其他一些查询。SQLite是一个同步执行查询的数据库。如果其他人正在使用该数据库，那么如果你执行查询或事务，它就会给出这个错误。

因此，停止正在使用特定数据库的进程，然后执行查询。

我在一个场景中得到了这个错误，与这里描述的略有不同。

SQLite数据库位于由3个服务器共享的NFS文件系统上。在其中2个服务器上，我能够成功地对数据库运行查询，在第三个服务器上，我认为我得到了“数据库已锁定”消息。

第三台机器的问题是，在/var上没有剩余空间了。每次我试图在位于这个文件系统的任何SQLite数据库中运行查询时，我都得到了“数据库被锁定”的消息，并且在日志上出现了这个错误:

Aug 8 10:33:38 server01 kernel: lockd: cannot monitor 172.22.84.87

还有这个:

Aug 8 10:33:38 server01 rpc。statd[7430]: Failed to insert: writing /var/lib/nfs/statd/sm/other.server.name.com: No space left on device .日志含义 Aug 8 10:33:38 server01 rpc。statd[7430]: STAT_FAIL to server01 for SM_MON of 172.22.84.87

太空的情况处理好之后，一切都恢复正常了。

如果你试图解锁Chrome数据库，用SQLite查看它，然后只需关闭Chrome。

窗户

%userprofile%\Local Settings\Application Data\Google\Chrome\User Data\Default\Web Data

or

%userprofile%\Local Settings\Application Data\Google\Chrome\User Data\Default\Chrome Web Data

Mac

~/Library/Application Support/Google/Chrome/Default/Web Data

在我编写的一个c# . net 4.6.1应用程序中，当它试图写入数据时，我也收到了sqlite锁，但在我的开发机器上的Visual Studio中运行该应用程序时却没有。相反，只有在远程Windows 10机器上安装并运行该应用程序时，才会出现这种情况。

最初我认为是文件系统权限，但事实证明是我使用Nuget在项目中安装的system . data . sqlite包驱动程序(v1.0.109.2)导致了这个问题。我删除了NuGet包，并在项目中手动引用了旧版本的驱动程序，一旦应用程序重新安装在远程机器上，锁定问题就神奇地消失了。只能认为是最新的驱动程序或Nuget包有bug。

我有一个工具“DB Browser for SQLite”正在运行，也在里面工作。显然，这个工具也会锁上东西。 在点击“写入更改”或“恢复更改”后，锁消失了，另一个进程(一个React-Native脚本)不再给出这个错误。

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

例如:

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

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

我在谷歌Chrome浏览器中查看存储的密码时遇到了这个错误。

# ~/.config/google-chrome/Default
$ sqlite3 Login\ Data
SQLite version 3.35.5 2021-04-19 18:32:05
sqlite> .tables
Error: database is locked

如果你不是特别关心父进程，或者你不想停止当前正在使用数据库的chrome进程，只需将文件复制到其他地方。

$ cp Login\ Data ~/tmp/ld.sql
$ sqlite3 ~/tmp/ld.sql .tables
field_info              meta   sync_model_metadata   
insecure_credentials    stats                 
logins                  sync_entities_metadata

这样做将允许您读取数据库的内容，而不打扰或停止主chrome进程。