让我们分别来看看每个情况以便找到我们如何解决这个问题。也让我们平衡SQL Server由于某种原因都有一个锁管理的事实。这是为了在一个高度一致的数据库环境中确保数据完整性。所以更改SQL Server的默认行为并不是一种好的做法，在做任何改动之前应该完全明白这一点。

　　报告所定

　　对于报告的情况，看看下面的选项是否是可能的。

　　l 对于特殊的和重复的报告，是否有可能在另外一个SQL Server例如一个报告服务器上执行这些报告呢?数据可以用很多种不同的方式复制(事务复制，日志传送，第三方复制等)，但是数据可能会稍微过期。尽管如此，它可能会阻止报告与联机事务处理应用程序竞争。

　　l 对于重复的报告，看看报告数据是否可以每分钟或者每5分钟预先汇总。数据再一次会轻微过期，但是可以计算值一次然后重复读取而不用每次执行查询时都导致基本表上的锁定问题发生。当执行计算时，锁定只在一分钟或者每五分钟发生一次。

　　l 如果这些选项都是不可能的，那么考虑下面的：

　　如果读取你应用程序中的脏数据没有问题并且报告应用程序支持会话级别参数，那么考虑从报告应用程序中使用更改每个会话的隔离级别。最有可能的情况是：它们遵循READ COMMITTED的SQL Server(2000和2005) 默认的隔离级别。READ COMMITTED隔离级别不允许读取脏数据也避免非重复的读取。同样地，适合于你环境的隔离级别可能是READ UNCOMMITTED，因为没有一个共享锁是执行的，也没有一个独占锁是光荣的。就在哪里和如何更改你应用程序中的隔离级别而言，参考你报告工具中的文档。

　　这是包含在你的报告应用程序中的SQL Server会话开始处的示例代码：

　　　SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
　　GO

　　联机事务处理锁定

　　在联机事务处理应用程序锁定视图的情况下，使用某个非默认隔离级别可能是不理智的，因为你不想降低一致性，也不想从整个会话中读取脏数据。在这种情况下，你可能只想把　NOLOCK提示增加到你的SELECT语句中仅用于代码集。记住有了NOLOCK提示，没有一个共享锁会执行也没有独占锁会很荣幸。