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

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

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

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

DECLARE @table_name sysname
DECLARE ROY_table CURSOR FOR
SELECT name FROM sysobjects where xtype  in ('u','s')
OPEN ROY_table
FETCH NEXT FROM ROY_table INTO @table_name
WHILE @@FETCH_STATUS = 0 
BEGIN
DBCC CheckTable (@table_name)
PRINT '--------------数据表'+@table_name + '的检查整理完成------------------'
FETCH NEXT FROM ROY_table INTO @table_name
END
CLOSE ROY_table
DEALLOCATE 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．下面执行真正的恢复操作，重建数据库日志文件

go
dbcc 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 设置为单用户状态

go
exec sp_dboption 'work_yf', 'single user', 'true'
go    
reconfigure   with   override

--1) 快速修复          REPAIR_FAST
--2) 重建索引并修复     REPAIR_REBUILD
--3) 允许丢失数据修复    REPAIR_ALLOW_DATA_LOSS

use work_yf
GO
DBCC CheckTable (PDE_LIST_ORG_HISTROY,REPAIR_REBUILD)
GO
DBCC CheckTable (PDE_LIST_ORG,REPAIR_REBUILD)
GO
DBCC CheckTable (PDE_HEAD,REPAIR_REBUILD)

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

GO
DROP STATISTICS PDE_HEAD._WA_Sys_STATUS_276EDEB3
GO
DBCC CheckTable (SYSINDEXES,REPAIR_REBUILD)
GO

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

 use   master  
 go   
 DBCC CheckDB (work_yf)

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


--12．设置数据库为正常状态

exec sp_dboption 'work_yf', 'single user', 'false'
go
update sysdatabases set status=28 where dbid=DB_ID('work_yf')

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

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

总结：

use   master  
go  
exec sp_configure   'allow updates',1   --允许修改系统目录
go
reconfigure   with   override  --更新配置
go
update sysdatabases set status=-32768 where dbid=DB_ID('AIS20200120090843') --数据库更改为紧急模式
go
-----下面是重建日志文件，可以先不执行，如果dbcc checkdb('AIS20200120090843')检查完毕不是0个一致性错误，需要执行，执行此句其他语句也要执行
--dbcc rebuild_log('AIS20200120090843','D:\金蝶账套\AIS20200120090843_log.ldf')  --重建日志
go
-----上面是重建日志文件，可以先不执行，如果dbcc checkdb('AIS20200120090843')检查完毕不是0个一致性错误，需要重建日志，执行此句其他语句也要执行
dbcc checkdb('AIS20200120090843')   --数据库一致性校验
update sysdatabases set status=28 where dbid=DB_ID('AIS20200120090843') --恢复正常模式
go
exec sp_configure   'allow updates',0  --不允许修改系统目录
go
reconfigure   with   override   --更新配置
go