SQLServer 用 NOLOCK 扫描时碰到错误601 数据移动导致扫描中断怎么处理修复支持远程帮忙

当你在 SQL Server 中使用 NOLOCK 提示（或设置事务隔离级别为 READ UNCOMMITTED）进行查询时，如果遇到错误 601，提示“由于数据移动，无法继续扫描，原因 NOLOCK”，这确实是一个让人头疼的问题，这个错误并不意味着你的数据库彻底崩溃了，但它明确指出了底层数据存储存在一些不一致的情况，下面将详细解释这个错误的原因以及如何处理。

错误 601 的根本原因

要理解这个错误,需要简单知道 SQL Server 如何存储数据，数据存储在称为“页”的单元中，为了快速找到数据，SQL Server 使用一种叫做“索引分配映射（IAM）”的结构来跟踪哪些页属于一个表或索引。

当你使用 NOLOCK 提示时，你是在告诉 SQL Server：“我要读取数据，但我不在乎其他事务是否正在修改这些数据，我也不想被锁挡住，你直接给我当前能看到的任何数据就行。” 这种读取方式被称为“脏读”。

在这种“脏读”模式下，查询优化器可能会选择一种称为“分配顺序扫描”的扫描方式，这意味着它会沿着 IAM 链所指示的物理分配顺序，一页一页地读取数据，问题就出在这里：在扫描的过程中，如果数据库的某些并发操作（在线索引重建、某些类型的更新操作等）移动了数据页的物理位置（即发生了“数据移动”），那么扫描进程之前基于旧 IAM 链记录的“下一个页”的指针可能就失效了，它按照指针去找下一页，却发现那个位置已经不是它期望的数据了，就像一个寻宝者按照旧地图找到一个地点，却发现宝藏已经被移走了，这时，SQL Server 就会抛出 601 错误，中止扫描，以防止返回错误或损坏的数据。

简而言之,错误 601 是 NOLOCK 扫描的“天性”使然，它牺牲了一致性来换取读取速度，而 601 错误就是这个交易中可能出现的代价之一，它不是一种数据损坏，而是一种在高速读取下遇到并发架构变更时产生的预期内冲突。

如何处理和修复

处理 601 错误的核心思路有两个方向：一是临时解决当前报错的查询，让它能正常运行；二是从长远考虑，评估是否必须使用 NOLOCK，并从根本上优化数据库。

立即解决当前查询

• 重试查询：最简单直接的方法，因为数据移动操作通常是瞬时的，在错误发生后的很短时间内，IAM 链已经更新完毕，恢复了稳定状态，此时再次运行相同的查询，很可能就成功了，这是一种非常常见且有效的临时应对措施。
• 移除 NOLOCK 提示：如果业务场景允许，尝试去掉查询中的 NOLOCK 提示，在不使用 NOLOCK 的正常读取（如默认的 READ COMMITTED 隔离级别）下，SQL Server 会使用一种能保证逻辑顺序一致性的扫描方法，它会维护扫描的稳定性，即使发生数据移动也不会导致 601 错误，这可能会因为遇到锁等待而降低查询速度。
• 使用快照隔离：如果数据库已启用“快照隔离”或“读取已提交快照”（RCSI），这是一个非常好的替代方案，你可以将事务隔离级别设置为 READ COMMITTED SNAPSHOT（数据库级别设置）或在查询中使用 SET TRANSACTION ISOLATION LEVEL SNAPSHOT，快照隔离能提供语句级或事务级的一致性视图，读取操作不会阻塞写操作，写操作也不会阻塞读操作，并且完全避免了脏读和 601 错误，这是现代 SQL Server 应用中推荐取代 NOLOCK 的方式。

调查和根除根本原因

601 错误频繁发生，说明数据库环境中存在大量的并发数据移动操作，这就需要深入调查。

• 识别触发数据移动的活动：使用 SQL Server 的动态管理视图（DMVs）来监控当时数据库正在进行的活动，重点检查：
  • 是否有大型的索引维护操作（如 ALTER INDEX ... REORGANIZE 或 ALTER INDEX ... REBUILD）正在线上运行？在线索引重建是导致数据移动的常见原因。
  • 是否有大量的 UPDATE 语句正在执行，这些更新是否导致了页拆分（当一页数据满后，需要将一半数据移到新页）？
  • 是否有统计信息更新或其他后台任务在运行？
  • 可以通过查询 sys.dm_exec_requests 等 DMV 来查看当前正在执行的请求。
• 优化索引和维护策略：
  • 调整维护窗口：如果发现是定期的索引维护任务导致了业务高峰期的 601 错误，应考虑将这类资源密集型、会引起数据移动的操作安排到业务低峰期进行。
  • 检查索引碎片：如果索引碎片化严重，不仅影响性能，也会增加维护操作（如重建）的频率和时长，定期检查并保持合理的索引碎片水平很重要。
  • 评估索引设计：是否存在缺失的索引导致查询被迫进行低效的表扫描？增加合适的索引可能让查询避免全表扫描，从而降低碰到数据移动的几率。

关于数据损坏的说明

虽然 601 错误本身通常不是数据损坏，但它有时会与真正的存储 corruption 错误（如著名的 824 错误）同时发生，或者在某些极端情况下，可能暗示底层存储存在问题，如果上述所有方法都无法解决问题，并且错误持续出现，那么作为最后的手段，需要检查数据库的完整性。

• 运行 DBCC CHECKDB：这是一个强大的命令，用于检查整个数据库的逻辑和物理完整性，在执行重要操作前，务必对数据库进行完整备份，命令很简单：DBCC CHECKDB('YourDatabaseName')。CHECKDB 报告了错误，那么问题就比 601 错误本身更严重，需要根据 CHECKDB 输出的具体错误信息进行修复，这可能涉及从备份中恢复等更复杂的操作。

关于远程帮忙的支持

寻求远程协助是处理复杂数据库问题的有效途径,如果内部团队缺乏经验，可以联系微软官方技术支持或寻找可信赖的第三方数据库专家，在寻求远程帮助时，请准备好以下信息，以便专家能快速定位问题：

• 完整的错误消息和日志。
• 发生错误时正在执行的 SQL 查询语句。
• SQL Server 的版本和版本号。
• 错误发生的频率和具体时间点。
• 当时数据库的负载情况（通过 DMV 查询到的活动会话信息等）。

SQL Server 的 601 错误是 NOLOCK 提示的一个已知局限性，处理时应优先考虑通过重试或改用快照隔离等更安全的方法来绕过问题，继而再深入调查并优化引起频繁数据移动的根本原因，从而在保证数据一致性的前提下，维持数据库的性能和稳定性。