SQL 2008+ NOLOCK与READPAST报告准确性的注意事项

Question

了解最终决策是商业决策，NOLOCK＆amp;在SQL 2008 R2中运行的READPAST？在讨论业务领域的变化之前，我希望有一个更好的理解。

我继承了许多查询，用于为管理报告创建数据视图。 'WITH（NOLOCK）'被广泛使用但不一致。正在读取的数据来自广泛使用的应用程序的生产服务器，该应用程序不断更新。我们正在从SQL 2005服务器迁移到SQL 2008 R2服务器。这些报告希望数据比存档服务器上的24小时数据更新鲜。使用NOLOCK表明过去的决定;存在冲突的可能性，并且可以接受一些准确性损失。数据用于填充仪表板以供人类意识/决策制定。

所有查询都是SELECT，具有数据视图登录的只读访问权限。大多数查询是单表，有几个2和3表连接。鉴于连接的低级别（）似乎比SET TRANSACTION ISOLATION LEVEL {}

更好的选择

表提示（Transact-SQL）http://msdn.microsoft.com/en-us/library/ms187373.aspx（以及关于SO的多个问题）表示除了缺少锁定记录之外，NOLOCK和/或READUNCOMMITTED可能会有重复的读取问题。

READPAST看起来更准确，因为它只会错过锁定的记录而不会有重复的记录。但我不确定丢失锁定记录的级别在它和NOLOCK之间是否一致。

蒂姆·查普曼（Tim Chapman）有一篇很好的文章比较了这两篇文章，但它写于2007年，大部分评论都围绕着2000年和2000年左右。 2005年有一条评论指出READPAST在2008 R2中存在问题

参考文献

Effect of NOLOCK hint in SELECT statements

When should you use "with (nolock)"

Using NOLOCK and READPAST table hints in SQL Server (By Tim Chapman)

修改

以下两个答案中建议了快照隔离。快照隔离是数据库的依赖设置，此Q / A https://serverfault.com/questions/117104/how-can-i-tell-if-snapshot-isolation-is-turned-on描述了如何查看数据库上的设置。我现在知道它已被禁用，我正在阅读来自主要应用程序数据库的报告。无法更改设置。 + - 几率的准确度是可以接受的，应用程序（OLTP）的影响是不可接受的。大多数简单查询不需要锁定考虑因素，但在某些极端情况下，需要锁定考虑因素。随着SQL 2005的Snapshot隔离的出现，NOLOCK＆amp; amp; SQL 2008或更高版本中的READPAST行为。然而，他们仍然是我唯一的选择。

Answer 1

值得考虑的更好选择是为数据库本身启用READ COMMITTED SNAPSHOT。这使用tempdb中的版本控制来捕获事务开始时表的状态。

关于NOLOCK，READPAST等各个方面的非常好的阅读，http://www.brentozar.com/archive/2013/01/implementing-snapshot-or-read-committed-snapshot-isolation-in-sql-server-a-guide/

如果有人在您选择表时更新表，则

WITH (NOLOCK)可能会提供错误的结果。如果在您阅读表时由于插入而发生页面拆分，并且新页面恰好超出了您已阅读的点，WITH (NOLOCK)将已从旧页面返回行，并且然后将从新页面返回重复的行。这只是(NOLOCK)为什么不好的一个例子。

当您从表中读取时，

WITH (READPAST)将跳过正在更新或插入的所有记录。在繁忙的数据库中，这两种选择都不好。

根据您最近编辑的问题，您声明无法更改READ COMMITTED SNAPSHOT的数据库设置，或许您应该考虑使用存储过程为报告收集数据，并将事务隔离级别设置为使用SET TRANSACTION ISOLATION LEVEL SNAPSHOT;存储过程的开头。为此，您需要更改数据库选项“允许快照隔离”。

从SQL Server联机丛书：

快照

指定事务中任何语句读取的数据将是事务开始时存在的事务一致的数据版本。事务只能识别在事务开始之前提交的数据修改。在当前事务开始之后由其他事务进行的数据修改对于在当前事务中执行的语句是不可见的。效果就好像事务中的语句获得了在事务开始时存在的已提交数据的快照。

除了恢复数据库之外，SNAPSHOT事务在读取数据时不会请求锁定。读取数据的SNAPSHOT事务不会阻止其他事务写入数据。写入数据的事务不会阻止SNAPSHOT事务读取数据。

在数据库恢复的回滚阶段，如果尝试读取被回滚的另一个事务锁定的数据，SNAPSHOT事务将请求锁定。在该事务已回滚之前，SNAPSHOT事务将被阻止。锁定在被授予后立即释放。

必须先将ALLOW_SNAPSHOT_ISOLATION数据库选项设置为ON，然后才能启动使用SNAPSHOT隔离级别的事务。如果使用SNAPSHOT隔离级别的事务访问多个数据库中的数据，则必须在每个数据库中将ALLOW_SNAPSHOT_ISOLATION设置为ON。

无法将事务设置为以另一个隔离级别启动的SNAPSHOT隔离级别;这样做会导致事务中止。如果事务在SNAPSHOT隔离级别启动，您可以将其更改为另一个隔离级别，然后再返回到SNAPSHOT。事务在第一次访问数据时启动。

在SNAPSHOT隔离级别下运行的事务可以查看该事务所做的更改。例如，如果事务对表执行UPDATE，然后针对同一表发出SELECT语句，则修改后的数据将包含在结果集中。

Answer 2

NOLOCK可能会导致重复数据被读取，数据被丢失以及查询实际失败并显示错误消息（带有“数据移动”的内容）。

另一方面，非NONLOCK查询可以也读取重复数据和错误数据！它绝不是数据库的一致快照。不同之处在于它不会读取未提交的数据，也不会失败。

NOLOCK的问题主要在于它可能会随机失败，因此您需要重试。此外，读取错误数据的概率略高。

在进行表扫描时，

NOLOCK具有很大的优势：SQL Server可以使用分配顺序扫描而不是索引顺序扫描。 TABLOCK具有相同的效果。在存在碎片的情况下，这可能是一个显着的加速。

考虑使用快照隔离级别，因为它摆脱了所有这些问题。它带来了一些其他权衡，你没有得到分配顺序扫描。但它永久而全面地消除了锁定问题。

Answer 3

在使用SQLQueryStress http://www.datamanipulation.net/sqlquerystress/进行压力测试后回答我自己的问题（这是一个非常好用的精彩工具）。 SQLQueryStress的结果针对SQL Server Profiler进行了测试;精度与SQL Server Profiler相同，但进动是两位小数，少于一秒（但对于此测试来说已足够）。

正如问题所述，主要关注的是应用程序性能影响，报告的准确性和性能是次要考虑因素。所有测试都发生在测试服务器上，测试应用程序处于活动状态并且具有一些次要活动。

下载并熟悉SQLQueryStress后，我设置了一个简单的“ReportQuery”来充当资源。它设置为15个线程运行15次迭代（总共225次查询）。总运行时间约为28秒，平均迭代时间为1.49秒。

创建一个Add / Delete'ApplicationQuery'来表示正在进行的应用程序活动。它设置为使用1个线程运行2000次迭代。有两个版本，带有一个select语句（运行31秒）而没有select语句（运行28秒）。这些代表正常的峰值时间应用活动。

运行三个版本的“ReportQuery”中的每一个的10次测试运行，这是为了确定'with（nolock）'，'with（readpast）和没有提示之间是否存在任何性能优势。结果表明ReportQuery在大约28秒内不断运行，平均1.5秒迭代时间没有显着差异。

没有大的异常值，因此决定在以下测试中进行5次测试。

使用select语句对ApplicationQuery进行5次测试运行;三个版本的“ReportQuery”中的每个版本之一也在运行。在15个总计测试中的每一个中，手动启动ApplicationQuery，之后立即手动启动ReportQuery。此方案表示资源繁重的报表查询在应用程序正在进行的资源活动中挣扎。

重复测试运行，但这次使用ApplicationQuery而没有select语句。

结果：在每种情况下，当ReportQuery运行时，ApplicationQuery被限制回几乎没有前进的进度。

在使用多个ApplicationQuery针对数据库进行资源争夺时，ReportQuery没有显着的性能损失。

ApplicationQuery能够运行与ReportQuery并行的查询，但在竞争资源时进展非常缓慢。本质上，运行2000应用程序添加/删除查询的总时间延长了ReportQuery使用的时间。

最初的问题是关于哪个更准确，变得毫无意义。使用或不使用提示NOLOCK或READPAST之间基本上没有报告或应用程序性能差异，因此不要在繁忙的数据库中使用它们并尽可能获得最高的准确性。

“ReportQuery”

select 
ID
, [TABLE_NAME]
, NUMBER
, FIELD
, OLD_VALUE
, NEW_VALUE
, SYSMODUSER
, SYSMODTIME
, SYSMODCOUNT

from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 

where Number like '%'
or NUMBER like '2010-01-01'

'ApplicationQuery'（使用Select语句）

select * 

from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 
where FIELD = 'JJTestingPerformance'


insert into dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 (ID
, [TABLE_NAME]
, NUMBER
, FIELD
, OLD_VALUE
, NEW_VALUE
)

values ('Test+Time'
, 'none'
, 'tst01'
, 'JJTestingPerformance'
, 'No Value'
, 'Test'
)

delete from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1

where FIELD = 'JJTestingPerformance'

'ApplicationQuery'（没有Select Statement）

insert into dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 (ID
, [TABLE_NAME]
, NUMBER
, FIELD
, OLD_VALUE
, NEW_VALUE
 )

values ('Test+Time'
, 'none'
, 'tst01'
, 'JJTestingPerformance'
, 'No Value'
, 'Test'
)

delete from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1

where FIELD = 'JJTestingPerformance'