首页 > 代码库 > 试图从数据库 ‘UFData_001_2003' 中提取的逻辑页 (1:10720) 属于对象 '0',而非对象 'syscolumns'

试图从数据库 ‘UFData_001_2003' 中提取的逻辑页 (1:10720) 属于对象 '0',而非对象 'syscolumns'

数据库可以使用,可以备份,但对备份进行恢复时报错,使用sp_attach_db对两个物理文件进行连接时,报同样错误:
服务器: 消息 605,级别 21,状态 1,行 1
试图从数据库 ‘UFData_001_2003‘ 中提取的逻辑页 (1:10720) 属于对象 ‘0‘,而非对象 ‘syscolumns‘。
连接中断
注:严重级别 21:数据库 (dbid) 进程中的 SQL Server 严重错误
这些消息表明遇到了影响当前数据库中所有进程的问题;但数据库本身损坏的可能性不大


错误分析

针对报的错误,数据有恢复的可能性
错误可能syscolumns这个系统表存储页受到了破坏,恢复的关键在于正确修复这个表

恢复步骤1-连接数据库
一、 建立一个同名的新数据库,方法同建账
二、 停止SQL Server服务,删除新数据库的两个文件,把备份中的ufdata.mdf COPY到相应的文件夹下
三、 启动SQL Server服务,运行SQL脚本,置数据库为紧急状态(emergency mode)
四、 重启SQL Server服务,重建LDF文件
连接成功!
五、 运行SQL脚本,置数据库为紧急状态
sp_configure ‘allow updates‘, 1 --指定可以直接更新系统表
go
reconfigure with override --如果配置不需要重启服务,则配置值直接
go --改运行值
use master
go
update sysdatabases set status = 32768 --该参数为置为紧急状态
where name = ‘ufdata_003_2003‘
go
sp_configure ‘allow updates‘, 0
go
reconfigure with override

恢复步骤1-连接数据库 脚本2

重建LDF文件
dbcc rebuild_log( ‘ufdata_001_2003‘, ‘E:\U8SOFT\ZT001\2003\ufdata.ldf‘)
注:之前必须重启SQL Server 服务

恢复步骤2-修复系统表

一、确定错误表 syscolumns
运行 select * from syscolumns
报错同前报错-->确定错误根源

二、运行DBCC修复

恢复步骤2-修复系统表-脚本1
sp_dboption ‘ufdata_002_2003‘,‘SINGLE USER‘, TRUE
go
DBCC CHECKTABLE (‘syscolumns‘,REPAIR_REBUILD )
go
sp_dboption ‘ufdata_002_2003‘, ‘SINGLE USER‘, FALSE
go

部分错误信息:
CHECKTABLE 发现了 0 个分配错误和 3 个一致性错误(在表 ‘syscolumns‘ 中,该表的对象 ID 为 3)。
repair_allow_data_loss 是最低的修复级别(对于由 DBCC CHECKTABLE (UFDATA_002_2003.dbo.syscolumns repair_rebuild) 发现的错误而言)。

恢复步骤2-修复系统表-脚本2
更高级别的修复方式 sp_dboption
‘ufdata_003_2003‘,‘SINGLE USER‘, TRUE
go
DBCC CHECKTABLE (‘syscolumns‘,REPAIR_ALLOW_DATA_LOSS )
go
sp_dboption ‘ufdata_003_2003‘, ‘SINGLE USER‘, FALSE
go
运行结果显示,错误已经修复 成功!!!

试图从数据库 ‘UFData_001_2003' 中提取的逻辑页 (1:10720) 属于对象 '0',而非对象 'syscolumns'