MS SQL 并发，多余的锁

Posted 2023-05-08

【中文标题】MS SQL 并发，多余的锁

【英文标题】：MS SQL Concurrency, excess Locks

【发布时间】：2008-10-10 15:39:49

【问题描述】：

我在 ms sql 2000 上有一个数据库，一次被数百名用户访问。使用 Reporting Services 2005 访问同一数据库的大量报告。

当有大量报告正在运行并且人们同时使用数据库时，我们会看到阻塞进程达到系统开始为在这种情况下一段时间后进行的任何事务提供超时的水平。

是否有一种全局方法可以最大限度地减少阻塞，以便事务可以继续进行。

【参考方案1】：

如果更新不经常发生并且数据库主要用于报告，请使用乐观锁定。

SQL Server 有一个相当悲观的锁定默认值。

查看SQL Server Table Hints 可能会让您入门。

【参考方案2】：

报告可以使用WITH(NOLOCK)。

其他可能性是使用数据库的只读副本运行报告，或者使用针对报告需求进行了优化的数据库的数据仓库版本。

【讨论】：

我们要解决的问题是必须制作报告才能实时获取最新数据。这使得复制变得难以跟上。

您对最新的定义可能意味着编写数据的人必须等待——毕竟，他们可能会使报告无效......

【参考方案3】：

由于您已经在报告中使用 NOLOCK 提示和 READ UNCOMMITTED 隔离级别，因此调查需要转向传入的事务查询。这可能会变得很深。也许应用程序将事务保持打开的时间过长。也可能是您在其他一些查询卷中进行了大量表扫描或范围扫描，并且这些可能为长时间运行的事务持有共享锁。那些共享锁会阻止你的作者。

您需要开始查看 sp_lock，查看哪些类型的锁未完成，查看被阻塞的查询试图获取哪些锁，然后检查阻塞请求者的查询。

如果您不熟悉 SQL Server 锁定，这将对您有所帮助： Understanding SQL Server 2000 Locking

另外，也许您可​​以描述一下您的磁盘子系统。它可能尺寸过小。

【参考方案4】：

感谢大家的支持。我们为缓解这个问题所做的工作是创建一个新的数据库，每小时执行一次日志传送过程，以保持与真实数据库的同步。不需要实时数据的报告指向该数据库，而需要实时数据的报告则受到限制，因此只有少数人可以访问它们。该方法的缺点是数据将长达一小时不同步，我们只需要为此目的创建一个新服务器。此外，当日志传送过程运行时，每个连接都会在很短的时间内下降，但对于非常长的过程或报告来说可能是一个问题。在此之后，我将验证报告中的查询，以便了解可以优化的内容。谢谢，我会向整个 IT 部门推荐该网站。