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

最近在系统运行中发现了一个错误,错误信息如下:
错误信息:查询A201412C20568单证信息错误 ---> System.Data.OleDb.OleDbException: 由于数据移动,未能继续以 NOLOCK 方式扫描。

一开始我认为企业的数据库是SQL SERVER 2005以上的版本,使用了以下方式:
USE MASTER GO
 
 
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','dbo use only','false'  
GO

exec 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_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) 
go
 

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


--12.设置数据库为正常状态  
exec sp_dboption 'work_yf', 'single user', 'false'
go
exec 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 
 

 

 

 

你可能感兴趣的:(Lock)