看起来今天将是另一个垃圾。 我们最近用一个完整的怪物更新了我们的sql盒子，内核和ram的负载，然而我们坚持我们的旧数据库模式，这是crapola。
我们的旧的SQL框有问题，但没有像我们正在经历的新的一个，虽然在推出当天运行速度超快，在一个星期内，这是一个完整的混乱…
我们的几百人左右的.net应用程序在SQL框上产生了大量的死锁和超时，我们正在努力解决这个问题。 我们已经检查了所有的指标，而且他们现在已经很好了。 一些主要的表格太广泛了，触发器的数目太多了，但现在我们无能为力了。
对于多次尝试的用户来说，许多pid似乎都是一样的。
所以，例如…
User: user1 Time: 09:21 Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. User: user1 Time: 09:22 Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 等等….
当我们把数据库移到新的数据库时，它从旧数据库中恢复到新数据库。
如果任何人有任何build议，我们可以做，我会买他们多品脱。
这实际上更像是一个发展问题。 您可能需要咨询您的开发人员以确定正在使用的事务隔离级别。
Microsoft SQL Server默认隔离级别是读取已提交。 开发者应该知道并设置适当的交易级别。 通常build议尽可能使用最小限制的隔离级别，并尽可能避免使用可重复读取和可序列化隔离级别。
如果他们正在使用比默认更严格的隔离级别，比如Repeatable Read或者Serializable，那么应用程序将更倾向于locking问题。 如果他们使用比默认更严格的隔离级别，并且没有意识到他们正在这样做，那更糟。
微软首要的数据访问技术Entity Framework默认使用Serializable隔离级别。 这没有很好的logging或披露。 如果应用程序使用entity framework，而开发人员不了解这一事实，则开发人员可能需要查看数据库devise，以确定是否可以将事务隔离级别设置为“读取已提交”。
更多信息：
SET TRANSACTION ISOLATION LEVEL（Transact-SQL）
http://msdn.microsoft.com/en-us/library/ms173763.aspx
entity framework4.0中的事务和连接
http://blogs.u2u.be/diederik/post/2010/06/29/Transactions-and-Connections-in-Entity-Framework-40.aspx
我不是喝啤酒，但是你应该认真看看SQL Server分析器 – 这是一个分析工作量的有价值的工具，包括一些工具来帮助找出死锁的原因。
关于这个话题写了很多文章， 这个是足够全面的。 MSDN的官方文档也包含一些信息，虽然没有写得很好。
如果你有正确的索引，没有好的方法来解决这个问题，而不修复数据库模式和/或查询：特别是使用SNAPSHOT ISOLATION和READ COMMITTED SNAPSHOT进行testing 。 他们不是快速修复。
如果你不介意把新的野兽变成一个慢猪肉，你可以禁用并行 。 目前还不确定会有多大帮助。
最终频繁的死锁是由于数据库devise不足造成的，而且没有办法。
你有没有至less能够logging导致问题的查询？ 我的经验一直是绝大多数问题的负责人。
从错误消息看起来你正在运行SQL Server。 如果您正在运行2005或更好打开跟踪标志1222 DBCC TRACEON (1222, -1)它应该给你一些关于查询的信息。 一个糟糕的模式可能会导致问题，但我从来没有见过一个糟糕的模式直接导致死锁。 通常有一个解决方法。 慢速查询比导致常量死锁的查询更好。
得到一些被干扰的查询，我们可能会build议对它们进行一些更改。