我们在Stack Overflow SQL Server 2005数据库中看到了一些有害但罕见的死锁条件.
我附上了探查器,使用这篇关于解决死锁问题的优秀文章设置了一个跟踪配置文件,并捕获了一堆示例.奇怪的是,死锁写入始终是相同的:
UPDATE [dbo].[Posts]
SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
WHERE [Id] = @p0
另一个死锁声明各不相同,但它通常是对posts表的一些简单,简单的读取.这个人总是在僵局中被杀死.这是一个例子
SELECT
[t0].[Id], [t0].[PostTypeId], [t0].[Score], [t0].[Views], [t0].[AnswerCount],
[t0].[AcceptedAnswerId], [t0].[IsLocked], [t0].[IsLockedEdit], [t0].[ParentId],
[t0].[CurrentRevisionId], [t0].[FirstRevisionId], [t0].[LockedReason],
[t0].[LastActivityDate], [t0].[LastActivityUserId]
FROM [dbo].[Posts] AS [t0]
WHERE [t0].[ParentId] = @p0
要非常清楚,我们没有看到写/写死锁,而是读/写.
我们目前混合使用LINQ和参数化SQL查询.我们已添加with (nolock)到所有SQL查询中.这可能对一些人有所帮助.我们昨天修复了一个(非常)写得不好的徽章查询,每次运行时间超过20秒,每分钟运行一次.我希望这是一些锁定问题的根源!
不幸的是,我在大约2小时前遇到了另一个死锁错误.同样的症状,同样的罪魁祸首写.
真正奇怪的是,您在上面看到的锁定写入SQL语句是非常特定的代码路径的一部分.它仅在向问题添加新答案时执行 - 它使用新答案计数和最后日期/用户更新父问题.显然,这与我们正在进行的大量读取相比并不常见!据我所知,我们在应用程序的任何地方都没有进行大量的写操作.
我意识到NOLOCK是一个巨大的锤子,但我们在这里运行的大多数查询都不需要那么准确.如果您的用户个人资料已过期几秒,您会关心吗？
正如Scott Hanselman在这里讨论的那样,将NOLOCK与Linq一起使用有点困难.
我们正在调整使用的想法
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
在基本数据库上下文中,以便我们所有的LINQ查询都有此设置.没有它,我们必须在3-4行事务代码块中包装我们所做的每个LINQ调用(好吧,简单的读取,这是绝大多数),这很难看.
我想我有点沮丧的是,SQL 2005中的琐碎读取可能会使写入死锁.我可以看到写/写死锁是一个很大的问题,但 …
我在ASP.NET MVC/SQL Server中有一个非常受欢迎的站点,不幸的是发生了很多死锁.虽然我试图通过SQL分析器找出它们出现的原因,但我想知道在执行死锁时如何更改SQL Server的默认行为.
是否可以重新运行导致问题的事务而不是显示错误屏幕？
我正在查看SQL Server 2005 上SP_WhoIsActive的输出，它告诉我一个会话阻止了另一个会话-很好。但是，它们都在运行SELECT。一个SELECT如何阻止另一个？他们俩不应该都获得共享锁（彼此兼容）吗？
更多详细信息：这两个会话都没有开放的事务计数-因此它们是独立的。
查询将视图与表连接在一起。
它们是复杂的查询，它们连接许多表并导致10,000次左右的读取。
任何见解非常感谢。