0

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

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

是否有一种将阻塞最小化的全局方法，以便事务可以继续流动。

4

4 回答 4

1

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

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

查看SQL Server 表提示可能会让您入门。

于 2008-10-10T15:42:24.213 回答
1

报告可以使用WITH(NOLOCK).

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

于 2008-10-10T15:54:58.103 回答
1

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

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

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

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

于 2008-10-10T16:20:05.837 回答
0

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

于 2008-10-10T19:35:25.740 回答