数据库锁定问题？

Question

我在 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是否曾经锁定消息处理。

希望有人可以提供帮助。我可以提供尽可能多的信息来提供帮助。

Answer 1

尝试打开读提交快照隔离(RCSI)（但请注意，这会给您的 tempDB 带来更大的压力，理想情况下，tempDB 应该位于其自己的一组专用物理轴上）。

从 SQL Server 2005 开始，有两个“快照”级别可用： READ COMMITTED SNAPSHOT 执行乐观读取和悲观写入；而 SNAPSHOT ISOLATION 执行乐观读取和乐观写入。建议您尝试一下RCSI。

启用基于行版本控制的隔离级别

要更改此设置，您需要切换到单用户模式以确保没有正在进行的查询（然后会失败）：

ALTER DATABASE dbname 
SET SINGLE_USER WITH ROLLBACK IMMEDIATE; 
GO

ALTER DATABASE dbname
SET READ_COMMITTED_SNAPSHOT ON; 
GO

ALTER DATABASE dbname
SET MULTI_USER; 
GO