我在 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是否曾经锁定消息处理。
希望有人可以提供帮助。我可以提供尽可能多的信息来提供帮助。
如果我需要一张表来保存销售点交易，并且被告知我需要存储：
Country ID
Store Number
POS Terminal Number
Transaction Date
Item Code
Teller ID
Another Field
More Fields
现在，在这种情况下，唯一性将是：
国家/地区 ID、商店编号、POS 终端编号、交易日期、项目代码
我总是不确定是否最好将标识列作为主键 - 在这种情况下，可能是TransactionID INT NOT NULL PRIMARY KEY，然后是跨唯一字段的唯一约束。
或者，是否应该跨所有唯一字段创建主键？
TransactionId我猜的好处是，加入。要加入交易，您只需使用单个字段。我在许多领域都看不到 PK 的好处。（节省额外列的空间？）。
我们有一个由 SQL Server 2012 ( ServerA) 数据库组成的应用程序。不过，我们需要显示的一些数据来自另一个数据库，但它是 SQL Server 2008 ( ServerSOURCE)。该数据库也位于单独的服务器上。
计划是在与 ServerA 相同的服务器上创建一个复制数据库，称为ServerREP，并将数据从 复制ServerSOURCE到ServerREP。但是我们只需要 ServerSOURCE 中的某些表。这是表的一小部分。ServerSOURCE有数百张桌子。我们只需要10个左右。
此外，表格中的数据可以减少。例如，假设我们有一个 Person 表，它有一个PersonTypeId. 我们只想要行where PersonTypeId = x。
这可以通过复制来实现吗？我们可以从源表的子集中获取数据子集到我们新的复制数据库中吗？是否类似于在源上创建一个 VIEW，然后将该视图的结果复制为复制数据库中的一个表？
我们正在尝试定义备份策略。我们打算申请以下内容：
但我们也在探索其他选项 - 事务日志备份和 Azure 备份（默认为 2 小时）
我是否正确地说差异备份会让我们到达上次差异备份，然后我们可以使用日志备份来接近我们想要恢复的位置？
因此，备份将如下所示：
自星期三以来每 2 小时 Inc - 日志备份。
让我们说灾难在周三中午来袭！
恢复差异，让我们在星期三凌晨 1 点...然后我们使用日志备份让我们在灾难发生之前到达。
这是类型之间的正确区分吗？