问题标签 [database-deadlocks]

在运行执行 INSERT 和 UPDATE 的存储过程（来自 .NET 应用程序）时，我有时（但实际上并不经常）随机收到此错误：

错误 [40001] [DataDirect][ODBC Sybase 有线协议驱动程序][SQL Server]您的服务器命令（系列 ID #0，进程 ID #46）遇到死锁情况。请重新运行您的命令。

我怎样才能解决这个问题？

谢谢。

我们有一个基于网络的应用程序。应用程序中有时间限制的数据库操作（插入和更新）需要更多时间才能完成，因此这个特定的流程已更改为 Java 线程，因此它不会等待（阻塞）完成完整的数据库操作。

我的问题是，如果超过 1 个用户遇到此特定流程，我将面临 PostgreSQL 引发的以下错误：

上述错误始终在 INSERT 语句中引发。

附加信息： 1）我在此表中定义了 PRIMARY KEY。2) 此表中有 FOREIGN KEY 引用。3) 将单独的数据库连接传递给每个 Java 线程。

技术 Web 服务器：Tomcat v6.0.10 Java v1.6.0 Servlet 数据库：PostgreSQL v8.2.3 连接管理：pgpool II

我正在寻找一种从 Java 6 应用程序中处理数据库死锁的好策略；几个并行线程可能同时写入同一个表。如果数据库 (Ingres RDMBS) 检测到死锁，它将随机终止其中一个会话。

考虑到以下要求，什么是处理死锁情况的可接受技术？

• 总经过时间应保持尽可能小
• 终止会话将导致显着（可测量的）回滚
• 时间线程无法相互
  通信，即策略应该是自治的

到目前为止，我想出的策略是这样的：

它可以以任何方式改进吗？例如等待固定数量（幻数）的秒数。是否有不同的策略可以产生更好的结果？

注意：将使用几种数据库级技术来确保死锁在实践中非常罕见。此外，应用程序将尝试避免调度同时写入同一个表的线程。上述情况只是“最坏的情况”。

注意：插入记录的表组织为堆分区表，没有索引；每个线程都会在自己的分区中插入记录。

如果以下情况是 mysql 中的错误？

mysql版本：mysql.x86_64 5.0.77-4.el5_4.1

内核：Linux box2 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

我的一位同事有一个存储过程，它执行以下
Begin tran
1) 动态生成一个 select 语句。
2) Insert into table x
3) 执行 select 语句
End tran

如果此存储过程由两个分隔线程同时运行，他会收到以下错误： System.Data.SqlClient.SqlException: Transaction (Process ID 57) was deadlocked on lock | 与另一个进程通信缓冲区资源，并已被选为死锁牺牲品。重新运行事务

这个存储过程真的是问题吗？从我天真的想法来看，这看起来更像是一种竞争条件，而不是僵局。

我有一个执行TableBto连接的存储过程TableA：

同时，在事务中，将行插入到TableA中，然后再插入到 中TableB。

这种情况偶尔会导致死锁，因为存储过程 select 从TableB抓取行，而 insert 将行添加到TableA，然后每个人都希望对方放手另一个表：

逻辑要求INSERT首先将行添加到A，然后添加到B，而我个人并不关心 SQL Server 执行连接的顺序 - 只要它连接即可。

修复死锁的常见建议是确保每个人都以相同的顺序访问资源。但在这种情况下，SQL Server 的优化器告诉我相反的顺序是“更好”。我可以强制执行另一个连接顺序，并且执行更差的查询。

但我应该吗？

我是否应该现在和永远使用我希望它使用的连接顺序来覆盖优化器？

或者我应该只捕获错误本机错误 1205，然后重新提交选择语句？

问题不是当我覆盖优化器并让它做一些非最优的事情时查询可能会执行多糟糕。问题是：自动重试比运行更糟糕的查询更好吗？

我有一个 MySQL 表，其中包含大约 5,000,000 行，这些行通过 DBI 连接的并行 Perl 进程以小方式不断更新。该表有大约 10 列和几个索引。

一种相当常见的操作有时会导致以下错误：

触发错误的 SQL 语句是这样的：

仅有时会触发错误。我估计只有 1% 的电话或更少。但是，小表从未发生过这种情况，并且随着数据库的增长而变得越来越普遍。

请注意，我使用 file_table 中的 a_lock 字段来确保我正在运行的四个几乎相同的进程不会尝试在同一行上工作。该限制旨在将他们的工作分成小块。

我没有对 MySQL 或 DBD::mysql 做太多调整。MySQL是标准的Solaris部署，数据库连接设置如下：

我在网上看到其他几个人报告了类似的错误，这可能是真正的死锁情况。

我有两个问题：

1. 我的情况到底是什么导致了上述错误？

2. 有没有一种简单的方法可以解决它或降低它的频率？例如，我究竟该如何进行“在 Db.pm 第 276 行重新启动事务”？

提前致谢。

什么是 SQL Server 中的死锁以及何时出现？

死锁有哪些问题以及如何解决？

我有一个 Oracle DB 包，它经常导致我认为是 ITL（感兴趣的事务列表）死锁。跟踪文件的相关部分如下。

此表上没有位图索引，所以这不是原因。据我所知，缺少“等待的行”加上等待列中的“S”可能表明这是一个 ITL 死锁。此外，该表的写入频率很高（大约同时插入或更新 8 次，每分钟最多 240 次），因此 ITL 死锁似乎很有可能。

我已将表的 INITRANS 参数及其索引增加到 100，并将表上的 PCT_FREE 从 10 增加到 20（然后重建索引），但死锁仍在发生。死锁似乎最常发生在更新期间，但这可能只是巧合，因为我只追踪了几次。

我的问题有两个：
1）这实际上是一个 ITL 死锁吗？
2）如果是ITL死锁，还有什么办法可以避免呢？

事实证明，这根本不是 ITL 死锁问题，而是未索引外键的问题。由于 dpbradley 的回答，我发现了这一点，这让我知道这不是 ITL 问题，并促使我找出“无行”死锁的其他原因可能是什么。

我们非常沮丧地在 MySQL 中遇到死锁。这不是因为超过锁定超时，因为死锁在发生时会立即发生。下面是在 2 个单独的线程（与连接池中有 2 个单独的连接）上执行的 SQL 代码，它会产生死锁：

序列表有 2 列：序列和计数器

LAST_INSERT_ID 允许我们按照 MySQL 的建议检索这个更新的计数器值。这对我们来说是完美的，但是我们遇到了这些僵局！我们为什么要得到它们，我们如何避免它们？

非常感谢您对此的任何帮助。

编辑：这一切都在事务中（因为我使用的是 Hibernate，所以需要）并且 AUTO_INCREMENT 在这里没有意义。我应该更清楚。Sequences 表包含许多序列（在我们的例子中大约有 1 亿个）。我需要增加一个计数器并检索该值。AUTO_INCREMENT 在所有这些中都不起作用，这与 Id 或 PRIMARY KEY 无关。