Question

我有一个相对较大的系统运行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

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

Answer 1

我建议您尝试一些选项..

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

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

SET LOCK_TIMEOUT 1800;
GO

索引数量：我们应该确定更多或更少的索引是否会改善死锁。如果大多数时间表扫描正在发生，则需要附加索引。如果存在不需要的索引，则需要更少的索引，这些索引在任何查询的查询计划中都没有使用，并且在每个INSERT，UPDATE和DELETE语句中需要更新这些不必要的索引，这也会增加这些语句的执行时间。增加陷入僵局的可能性。

TinyTDS超时和死锁很多

1 个答案: