1

我有一个相对较大的系统运行 Rails 和 TinyTds（使用 FreeTds 的 SQLServer 数据库适配器）。问题是我每天收到大约 200 封电子邮件，说我的请求超时或死锁。

[Exception] application#index (ActionView::Template::Error) "TinyTds::Error: Adaptive Server connection timed out: EXEC sp_executesql

它们总是发生在不同的动作上。

A ActiveRecord::DeadlockVictim occurred in transportes#importacao:

  TinyTds::Error: Transaction (Process ID 276) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

我不知道为什么它会超时这么多，并且已经在这些电子邮件中苦苦挣扎了将近 2 个月。我已经尝试更新 gem 版本，FreeTds 的 linux 二进制文件，但没有任何帮助。

目前使用 Ruby 1.9.3-p484、Rails 3.2.16 和 TinyTds 0.6.2

谁能给我一些关于如何解决这个问题的见解？

4

1 回答 1

1

我建议你几个选项，你可以尝试..

  • 默认情况下，数据库引擎选择运行回滚成本最低的事务的会话作为死锁牺牲品。或者，用户可以使用 SET DEADLOCK_PRIORITY 语句指定死锁情况下会话的优先级。DEADLOCK_PRIORITY 可以设置为 LOW、NORMAL 或 HIGH，或者可以设置为范围内的任何整数值（-10 到 10）。
  • 自定义锁定超时，当 Microsoft SQL Server 数据库引擎的实例由于另一个事务已经拥有资源上的冲突锁定而无法向事务授予锁定时，第一个事务将被阻塞，等待现有锁定被释放。默认情况下，没有强制超时期限，也没有办法在锁定资源之前测试资源是否被锁定，除非尝试访问数据（并可能无限期地被阻止）。

以下示例将锁定超时期限设置为 1800 毫秒。

SET LOCK_TIMEOUT 1800;
GO
  • 索引数量：我们应该确定增加或减少索引是否会改善死锁。如果大部分时间都在进行表扫描，则需要额外的索引。此外，如果存在未在查询计划中用于任何查询的不需要的索引，并且这些不必要的索引需要在每个 INSERT、UPDATE 和 DELETE 语句期间更新，则需要更少的索引，这会增加这些语句的执行时间，这也增加死锁的机会。
于 2015-03-11T09:28:45.050 回答