我试图在 SQL Server 中找到一些关于阻塞的信息，但我找不到关于它是什么以及它是如何发生的简明解释。你能帮我解惑吗？
大约每周一次，我必须解决 SQL Server 2005 数据库上的阻塞链，这是由 Access 2003 前端的长期读取锁引起的。每当用户打开某个表单时就会解除锁定，并在用户完成滚动表单或关闭表单后解除锁定。由于我们的许多用户打开此表单作为参考，因此这些锁会保留一段时间。对该表的任何更新都会导致阻塞，突然间没有人可以从该表中进行选择，因为他们都在等待第一个锁。这对我们来说是一个很大的问题，因为许多应用程序都依赖于这些数据。我知道这种锁定行为是 Access 如何处理链接表的一部分。
我一直在通过 Activity Monitor 解决这个问题，只要我发现它，就会杀死任何一个是 Head Blocker 的 SELECT 进程。这是一个问题，不仅因为我手动完成它需要时间，还因为它是被动的。当我听说它时，它已经成为很多人的问题。
我想知道是否有一种自动方法来检查这些持久的阻塞链，并通过电子邮件发送或自动解决问题。逻辑看起来很简单（“如果任何与此 SELECT 查询匹配的进程阻塞了超过一分钟，请通知我/杀死它”）但我不知道如何使用 SQL Server 实现这一点。
对于它的价值，我认为正确的解决方案是修复或重写应用程序。然而，由于部门政治，这不是未来几个月的选择，所以我正在寻找一个权宜之计。
我在 SQL Server 2008 生产数据库上遇到了与事务相关的问题。简要概述一下，我们有一个网站，该网站在该州拥有众多并发用户，他们通过 ASP.Net 网站执行 GUI 类型的工作（添加记录、修改、查看等）。
每个插入和更新都在它自己的事务中完成，由数据访问层处理。我相信，数据库隔离设置为 Read_Commited。
一切正常。
但是，已添加一个新模块，该模块轮询单独的数据库以获取信息。如果有新信息，一个进程会启动一个新事务，并使用相同的数据访问器代码从我们的数据库中读取，以及从另一个单独的数据库中读取新信息。然后它会进行大量检查以查看它必须对新数据做什么......然后开始对我们的数据库进行大量更新或插入。这一切都在一个大交易中。来自 UI 应用程序和轮询服务的所有插入和更新都经过相同的 CRUD 过程。由于要处理的传入消息可能包含许多需要更新的实体，因此完成事务的时间可能在瞬间到一分钟之间。
但是我们发现，当处理较大的消息时，UI 会锁定，并且可以为用户锁定 3 分钟。
因此，我们认为在选择中添加“NOLOCK”提示可能会有所帮助。它没有。好吧，它可能有所帮助，但锁定仍在发生。
我认为原因可能是消息到达，并且启动了一个事务，这导致其他事务无法工作（即使是 SELECT 语句，我也不明白）。分析数据库表明，即使是简单的选择也需要很长时间才能在 UI 上完成（简单，例如SELECT fields FROM SingleTable WHERE PrimaryKey = Value
我们的索引似乎没问题……我们在所有表上都有触发器，它们只是将更新和插入复制到 AUDIT 数据库表中。不要认为他们是问题所在。
我认为这是因为围绕消息处理的事务，这将 UI 锁定。
任何人都可以分享经验或告诉我在哪里可以查看为什么我们会遇到 UI 锁定？UI 应该有优先权。消息处理是后台的事情......用户需要优先......但似乎消息正在锁定数据库......我们不确定UI是否曾经锁定消息处理。
希望有人可以提供帮助。我可以提供尽可能多的信息来提供帮助。