修复发生“由于数据移动，未能继续以 NOLOCK 方式扫描”错误的数据库

最近在系统运行中发现了一个错误，错误信息如下：错误信息：查询A201412C20568单证信息错误 ---> System.Data.OleDb.OleDbException: 由于数据移动，未能继续以 NOLOCK 方式扫描。一开始我认为企业的数据库是SQL SERVER 2005以上的版本，使用了以下方式：

USE MASTERGO  ALTER DATABASE work_yf SET SINGLE_USERGO --允许丢失数据修复DBCC CHECKDB (work_yf, REPAIR_ALLOW_DATA_LOSS)GO ALTER DATABASE work_yf SET MULTI_USER 

在执行了命令之后，发现无法成功。后研究了一下企业使用的数据库，发现是SQL SERVER 2000的。所以只能使用以下方式进行修复。

第一步：通过以下代码查询，是哪些表中出错了

DECLARE @table_name sysnameDECLARE ROY_table CURSOR FORSELECT name FROM sysobjects where xtype  in ('u','s')OPEN ROY_tableFETCH NEXT FROM ROY_table INTO @table_nameWHILE @@FETCH_STATUS = 0 BEGINDBCC CheckTable (@table_name)PRINT '--------------数据表'+@table_name + '的检查整理完成------------------'FETCH NEXT FROM ROY_table INTO @table_nameENDCLOSE ROY_tableDEALLOCATE ROY_table

执行上述命名之后，会在“消息”窗口中显示如下信息：（以下信息中只有出错信息，其他正常信息已经去除）

服务器: 消息 8929，级别 16，状态 1，行 10对象 ID 2: 在文本 ID 177078272 中发现错误，该文本的所有者是由 RID = (1:135:19) id = 661577395 and indid = 3 标识的数据记录。服务器: 消息 8961，级别 16，状态 1，行 10表错误: 对象 ID 2。text、ntext 或 image 节点（位于页 (1:66)，槽 2，文本 ID 177078272）与该节点位于页 (1:284)，槽 6 处的引用不匹配。'sysindexes' 的 DBCC 结果。对象 'sysindexes' 有 304 行，这些行位于 14 页中。CHECKTABLE 发现了 0 个分配错误和 2 个一致性错误（在表 'sysindexes' 中，该表的对象 ID 为 2）。通过上面的提示信息，找到出错的索引或统计信息--------------数据表sysindexes的检查整理完成------------------服务器: 消息 8936，级别 16，状态 1，行 10表错误: 对象 ID 709577566，索引 ID 1。B 树链的链接不匹配。(1:2203)->next = (1:176)，但 (1:176)->Prev = (1:2045)。服务器: 消息 8977，级别 16，状态 1，行 10表错误: 对象 ID 709577566，索引 ID 1。未遇到页 (1:2203) 的父节点。'PDE_LIST_ORG' 的 DBCC 结果。对象 'PDE_LIST_ORG' 有 216 行，这些行位于 11 页中。CHECKTABLE 发现了 0 个分配错误和 2 个一致性错误（在表 'PDE_LIST_ORG' 中，该表的对象 ID 为 709577566）。repair_rebuild 是最低的修复级别（对于由 DBCC CHECKTABLE (work_yf.dbo.PDE_LIST_ORG ) 发现的错误而言）。--------------数据表PDE_LIST_ORG的检查整理完成------------------服务器: 消息 8978，级别 16，状态 1，行 10表错误: 对象 ID 725577623，索引 ID 1。页 (1:3891) 缺少上一页 (1:3892) 对它的引用。可能是因为链的链接有问题。服务器: 消息 8976，级别 16，状态 1，行 10表错误: 对象 ID 725577623，索引 ID 1。在扫描操作中未发现页 (1:3892)，而其父代 (1:2198) 和上一页 (1:3889) 指向了该页。请检查先前的错误。'PDE_LIST_ORG_HISTROY' 的 DBCC 结果。对象 'PDE_LIST_ORG_HISTROY' 有 16755 行，这些行位于 489 页中。CHECKTABLE 发现了 0 个分配错误和 2 个一致性错误（在表 'PDE_LIST_ORG_HISTROY' 中，该表的对象 ID 为 725577623）。repair_rebuild 是最低的修复级别（对于由 DBCC CHECKTABLE (work_yf.dbo.PDE_LIST_ORG_HISTROY ) 发现的错误而言）。--------------数据表PDE_LIST_ORG_HISTROY的检查整理完成------------------第二步，进行分析，除了上面的斜体字部分，需要注意，其他都很清楚，就是两张业务表发生了错误。而斜体字部分是指一张系统表sysindexes，需要进一步查询是哪些索引出错了。1） 使用以下语句检查是哪些索引出现了问题，原来是_WA_Sys_STATUS_276EDEB3出错是问题。

SELECT *  FROM SYSINDEXES WHERE  id = 661577395 and indid = 3 select * from sysobjects where id = 661577395

第三步，进行修得操作。具体操作方法如下：--方法如下:--1. 先停掉数据库服务器，把出问题的数据库（例如:work_yf）的.mdf与.ldf文件备份到备份目录中。--2．我们使用默认方式建立一个供恢复使用的数据库(如work_yf)。可以在SQL Server Enterprise Manager里面建立。 --3．停掉数据库服务器。 --4．将刚才生成的数据库的日志文件work_yf_log.ldf删除，用要修复的数据库mdf文件覆盖刚才生成的数据库数据文件work_yf_data.mdf。 --5．启动数据库服务器。此时会看到数据库work_yf的状态为“置疑”。这时候不能对此数据库进行任何操作。 --6．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，     在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 

use   master  go  exec sp_configure   'allow updates',1  go    reconfigure   with   override  go  

--7．设置work_yf为紧急修复模式 

update sysdatabases set status=-32768 where dbid=DB_ID('work_yf')  

--此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读/置疑/脱机/紧急模式”可以看到数据库里面的表，但是仅仅有系统表 --8．下面执行真正的恢复操作，重建数据库日志文件 

godbcc rebuild_log('work_yf','D:/Program Files/Microsoft SQL Server/MSSQL/Data/work_yf_log.ldf')  go

--执行过程中，如果遇到下列提示信息： --服务器: 消息 5030，级别 16，状态 1，行 1 --未能排它地锁定数据库以执行该操作。 --DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 --说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了work_yf库的系统表，   那么退出SQL Server Enterprise Manager就可以了。 --正确执行完成的提示应该类似于： --警告: 数据库 'work_yf' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。   将必须重置数据库选项，并且可能需要删除多余的日志文件。 --DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 --此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。 --9 设置为单用户状态

goexec sp_dboption 'work_yf','dbo use only','false'  GOexec sp_dboption 'work_yf', 'single user', 'true'go    reconfigure   with   override  

--10 修复表，具体要修复哪些表，请在执行DBCC CheckTable (表名) ，自行检查。我在这里使用了"重建索引并修复(REPAIR_REBUILD)"的选项。一共有三个选项：--1) 快速修复          REPAIR_FAST--2) 重建索引并修复     REPAIR_REBUILD--3) 允许丢失数据修复    REPAIR_ALLOW_DATA_LOSS

use work_yfGODBCC CheckTable (PDE_LIST_ORG_HISTROY,REPAIR_REBUILD)GODBCC CheckTable (PDE_LIST_ORG,REPAIR_REBUILD)GODBCC CheckTable (PDE_HEAD,REPAIR_REBUILD)

--刚才我在检查的时候，发现一个_WA_Sys_STATUS_276EDEB3也出错了，这是SQL SERVER自动建立的统计信息，所以需要进行删除，然后在进行修复

GODROP STATISTICS PDE_HEAD._WA_Sys_STATUS_276EDEB3GODBCC CheckTable (SYSINDEXES,REPAIR_REBUILD)GO

--11．验证数据库一致性（可省略） 

 use   master   go   DBCC CheckDB (work_yf) 

go

--一般执行结果如下： --CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'work_yf' 中）。 --DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 --12．设置数据库为正常状态 

exec sp_dboption 'work_yf', 'single user', 'false'goexec sp_dboption 'work_yf','dbo use only','false'  go

--如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。 --13．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成 

exec sp_configure   'allow updates',0  go    reconfigure   with   override  go