SQLite3::BusyException

Question

现在使用 SQLite3 运行 Rails 站点。

大约每 500 个请求一次，我得到一个

ActiveRecord::StatementInvalid (SQLite3::BusyException: 数据库被锁定:...

有什么方法可以解决这个对我的代码影响最小的问题？

我目前正在使用 SQLLite，因为您可以将数据库存储在源代码管理中，这使备份变得自然，并且您可以非常快速地推出更改。 然而，它显然并没有真正设置为并发访问。 明天早上我将迁移到 MySQL。

Answer 1

您提到这是一个 Rails 站点。 Rails 允许您在 database.yml 配置文件中设置 SQLite 重试超时：

production:
  adapter: sqlite3
  database: db/mysite_prod.sqlite3
  timeout: 10000

超时值以毫秒为单位指定。 将其增加到 10 或 15 秒应该会减少您在日志中看到的 BusyExceptions 的数量。

不过，这只是一个临时解决方案。 如果您的站点需要真正的并发，那么您将不得不迁移到另一个数据库引擎。

Answer 2

默认情况下，如果数据库忙且锁定，sqlite 会立即返回阻塞、忙错误。 您可以要求它等待并在放弃之前继续尝试一段时间。 这通常可以解决问题，除非您确实有 1000 个线程访问您的数据库，但我同意 sqlite 是不合适的。

// set SQLite to wait and retry for up to 100ms if database locked
    sqlite3_busy_timeout( db, 100 );

Answer 3

所有这些都是真的，但它并没有回答这个问题，这很可能是：为什么我的 Rails 应用程序偶尔会在生产中引发 SQLite3::BusyException？

@Shalmanese：生产托管环境是什么样的？ 是在共享主机上吗？ 包含 SQLite 数据库的目录是否位于 NFS 共享上？ （可能在共享主机上）。

这个问题可能与 NFS 共享的文件锁定现象和 SQLite 缺乏并发性有关。

Answer 4

如果您遇到此问题但增加超时不会改变任何内容，则您可能会遇到另一个事务并发问题，总结如下：

1. 开始一个事务（获得一个共享锁）
2. 从 DB 中读取一些数据（我们仍然使用SHARED锁）
3. 同时，另一个进程启动一个事务并写入数据（获取RESERVED锁）。
4. 然后你尝试写，你现在正在尝试请求RESERVED锁
5. SQLite立即引发 SQLITE_BUSY 异常（独立于您的超时），因为到获得RESERVED锁时，您之前的读取可能不再准确。

解决此问题的一种方法是通过将:immediate选项填充到驱动程序来修补active_record sqlite 适配器以在事务开始时直接获取RESERVED锁。 这会稍微降低性能，但至少您的所有交易都会遵守您的超时并一个接一个地发生。 以下是使用prepend (Ruby 2.0+) 将其放入初始化程序的方法：

module SqliteTransactionFix
  def begin_db_transaction
    log('begin immediate transaction', nil) { @connection.transaction(:immediate) }
  end
end

module ActiveRecord
  module ConnectionAdapters
    class SQLiteAdapter < AbstractAdapter
      prepend SqliteTransactionFix
    end
  end
end

在此处阅读更多信息： https : //rails.lighthouseapp.com/projects/8994/tickets/5941-sqlite3busyexceptions-are-raised-immediately-in-some-cases-despite-setting-sqlite3_busy_timeout

Answer 5

bundle exec rake db:reset

它对我有用，它将重置并显示挂起的迁移。

Answer 6

只是为了记录。 在 Rails 2.3.8 的一个应用程序中，我们发现 Rails 忽略了 Rifkin Habsburg 建议的“超时”选项。

经过更多调查，我们在 Rails 开发中发现了一个可能相关的错误： http : //dev.rubyonrails.org/ticket/8811 。 经过更多调查，我们找到了解决方案（使用 Rails 2.3.8 测试）：

编辑这个 ActiveRecord 文件：activerecord-2.3.8/lib/active_record/connection_adapters/sqlite_adapter.rb

替换这个：

  def begin_db_transaction #:nodoc:
    catch_schema_changes { @connection.transaction }
  end

和

  def begin_db_transaction #:nodoc:
    catch_schema_changes { @connection.transaction(:immediate) }
  end

就这样！ 我们没有注意到性能下降，现在该应用程序支持更多请求而不会中断（等待超时）。 Sqlite 不错！

Answer 7

大多数答案是针对 Rails 而不是原始 ruby​​ 的，OP 的问题是针对 Rails，这很好。 :)

因此，如果任何原始 ruby​​ 用户遇到此问题，并且不使用 yml 配置，我只想将这个解决方案留在这里。

实例化连接后，您可以这样设置：

db = SQLite3::Database.new "#{path_to_your_db}/your_file.db"
db.busy_timeout=(15000) # in ms, meaning it will retry for 15 seconds before it raises an exception.
#This can be any number you want. Default value is 0.

Answer 8

我对 rake db:migrate 有类似的问题。 问题是工作目录位于 SMB 共享上。 我通过将文件夹复制到我的本地机器来修复它。

Answer 9

Sqlite 可以允许其他进程等待当前进程完成。

当我知道可能有多个进程试图访问 Sqlite DB 时，我使用此行进行连接：

conn = sqlite3.connect('文件名', isolation_level = 'exclusive' )

根据 Python Sqlite 文档：

您可以通过connect()调用的isolation_level参数或连接的isolation_level属性来控制pysqlite隐式执行哪种BEGIN语句（或根本不执行）。

Answer 10

我在 sqlite3 ruby​​ 扩展上发现了一个死锁，并在这里修复它：试试看，看看这是否能解决你的问题。

https://github.com/dxj19831029/sqlite3-ruby

我打开了一个拉取请求，他们不再回复了。

无论如何，如 sqlite3 本身所述，预计会出现一些繁忙的异常。

请注意这种情况： sqlite busy

The presence of a busy handler does not guarantee that it will be invoked when there is 
    lock contention. If SQLite determines that invoking the busy handler could result in a 
    deadlock, it will go ahead and return SQLITE_BUSY or SQLITE_IOERR_BLOCKED instead of 
    invoking the busy handler. Consider a scenario where one process is holding a read lock 
    that it is trying to promote to a reserved lock and a second process is holding a reserved 
    lock that it is trying to promote to an exclusive lock. The first process cannot proceed 
    because it is blocked by the second and the second process cannot proceed because it is 
    blocked by the first. If both processes invoke the busy handlers, neither will make any 
    progress. Therefore, SQLite returns SQLITE_BUSY for the first process, hoping that this 
    will induce the first process to release its read lock and allow the second process to 
    proceed.

如果您满足此条件，则超时不再有效。 为避免这种情况，请不要将 select 放在 begin/commit 中。 或使用独占锁开始/提交。

希望这可以帮助。 :)

Answer 11

这通常是多个进程访问同一数据库的连续错误，即如果 RubyMine 中未设置“仅允许一个实例”标志

Answer 12

尝试运行以下命令，它可能会有所帮助：

ActiveRecord::Base.connection.execute("BEGIN TRANSACTION; END;") 

来自： Ruby：SQLite3::BusyException：数据库被锁定：

这可能会清除阻碍系统的任何事务

Answer 13

来源：这个链接

- Open the database
db = sqlite3.open("filename")

-- Ten attempts are made to proceed, if the database is locked
function my_busy_handler(attempts_made)
  if attempts_made < 10 then
    return true
  else
    return false
  end
end

-- Set the new busy handler
db:set_busy_handler(my_busy_handler)

-- Use the database
db:exec(...)

Answer 14

遇到锁时正在访问什么表？

你有长期运行的交易吗？

当遇到锁时，你能找出哪些请求仍在处理中吗？

Answer 15

啊——这是我上周存在的祸根。 当任何进程写入数据库时，Sqlite3 都会锁定 db 文件。 IE 任何 UPDATE/INSERT 类型查询（也出于某种原因选择 count(*)）。 但是，它可以很好地处理多次读取。

所以，我终于很沮丧，可以围绕数据库调用编写自己的线程锁定代码。 通过确保应用程序在任何时候都只能有一个线程写入数据库，我能够扩展到 1000 个线程。

是的，它慢得要命。 但它也足够快和正确，这是一个很好的属性。

Answer 16

我相信当交易超时时会发生这种情况。 您确实应该使用“真实”数据库。 像 Drizzle 或 MySQL 之类的东西。 有什么理由让您更喜欢 SQLite 而不是前面的两个选项？