0

我有以下情况:

  • 由多个程序访问(更新、删除、插入和选择)的表。实际上它们是相同的,但由多个用户实例化。该表永远不会增长到超过 1000 行,因为程序会在使用后删除数据并再次插入新数据。这就像供应商/收藏家的情况。

  • 由于这是一个工业生产场景,我必须保证一些操作,所以当用户确认任何操作时,程序会使用来自系统上其他表的数据更新该表。

所以我们在很多命令上实现了事务,结果是很多死锁的情况。

我想要一些关于我们可以做些什么来避免这些锁的提示。实际上我们不需要事务,我们只需要保证一个命令会运行,如果由于某种原因它失败了,整个操作就会被回滚。我不知道是否有办法在不使用事务的情况下做到这一点。

PS:我们使用的是 SQL Server 2008 R2。

PS2:我发现我在更新的 FROM 子句中使用的一些系统表是个大问题。这些表用于整个系统并获得大量的插入/更新/选择。所以我只是锁定了不应该的东西,因为我没有使用这个程序更改该表上的数据。

前任:

   Update t1
   set x= 1
   from systable1 as t
   inner join systable2 t2
   where .....

我想这是个大问题,所以我WITH (NOLOCK)在 t 和 t2 以及WITH (ROWLOCK)t1 上添加了提示。

我必须提到的另一件事是,这是一个测试环境,我们正在最大程度地强调数据库和程序,因为我们不能冒险在生产中失败。

如果失败,我可以使用检查点策略重新执行操作吗?

谢谢。

4

4 回答 4

0

您可以通过使用 READ UNCOMMITTED 来消除锁定问题(请参阅为什么使用 READ UNCOMMITTED 隔离级别?http://msdn.microsoft.com/en-us/library/aa259216(v=sql.80).aspx) . 但请注意,这可能会导致读取不一致或不一定会保留在数据库中的数据。

于 2012-04-26T23:12:18.613 回答
0

使用 readuncommitted 是一种可能的解决方案,尽管它会产生连锁反应。不过,我会先尝试行锁。SQL Server 对页锁进行了优化以减少记录上的锁数量,因为您只有一千条记录,除非它们非常宽,页锁将锁定其中的好几条。

于 2012-04-26T23:22:49.260 回答
0

首先对 Transaction 中的所有查询进行性能调优。有时,通过添加索引来加速事务内部的查询可能会对您看到的死锁数量产生很大影响。

此外,保持事务尽可能小,以便在出现故障时实现所需的回滚。例如,如果您有 5 个查询来查找数据,但只有 3 个查询会更改数据,那么您可以将事务缩减为仅更改数据的 3 个查询。

希望这可以帮助。

于 2012-04-26T23:24:40.750 回答
0

首先,是的,您需要事务来确保成功或失败(回滚)。只有 1,000 条记录?那张桌子一定被插入/更新/删除撞到了!所以对我来说,这听起来像是一个繁重的事务表——所以要小心添加索引,因为它们只会让你的插入/更新/删除变慢。而且我必须确认您的繁重事务表上没有触发器,对吗?

那么你的阅读量呢?有没有想过分离出报表或其他东西?复制可能是矫枉过正。数据需要多么准确和最新?

最后 - 个人资料,个人资料,个人资料。

于 2012-04-27T00:40:01.137 回答