前两天在论坛，看到有个网友提问，说是： 格式化磁盘前把.mdf和.ldf拷贝出来了，然后格式化完成后在拷贝回去（拷贝前后都没有错误提示，文件大小也一样），在企业管理器中附加数据库出错，提示错误823，附加数据库失败。从网上搜了搜方案：重建同名数据库之

前两天在论坛，看到有个网友提问，说是：

格式化磁盘前把.mdf和.ldf拷贝出来了，然后格式化完成后在拷贝回去（拷贝前后都没有错误提示，文件大小也一样），在企业管理器中附加数据库出错，提示“错误823”，附加数据库失败。从网上搜了搜方案：重建同名数据库之类的做法都试过了，都不能解决问题。请问版主或各位高手，有什么解决方案吗？
注：拷贝之前数据库使用正常，并且以前都是此种方法附加的，这次不知如何出现这样的问题了。

帮他尝试恢复：

1、他已经按照网上的方法，新建了一个同名的数据库。

2、停止服务，然后把原始的文件拷贝到目录中。

3、启动服务，发现数据库处于质疑状态。

4、运行如下命令，都报错：打不开数据库

dbcc checkdb(xxx);

dbcc checkdb(xxx,repair_allow_data_loss);

5、运行如下命令成功， 设置数据库为紧急模式

 Use Master 
 GO 
 
 sp_configure 'allow updates', 1 
 reconfigure with override 
 GO 
 
 UPDATE sysdatabases SET status = 32768 where name = 'xxx' 
 GO 

dbcc checkdb(xxx,repair_allow_data_loss);

alter database test set single_user

dbcc checkdb(xxx,repair_allow_data_loss);

在网上找了一下，发现有很多人都有这个问题，但是没有解决办法。

9、尝试运行如下命令，但类似这样的报错：

服务器: 消息 09，级别 16，状态 1，行 1
表错误: 对象 ID 0，索引 ID 0，页 ID 0。
 服务器: 消息 66，级别 16，状态 1，行 1
未能读取并闩锁页 (1:123456)（用闩锁类型 SH）。sysobjects 失败。

sql server 系统表损坏修复方法 http://wenku.baidu.com/view/901cd511f18583d049592e

这个文章中提到的解决方法就是，新建一个数据库，通过dts，把原来数据库的数据，导出到新的数据库中，但前提是其中的表都能访问，也就是能够select * from 表，否则就没用了。

那么有没有什么好的办法，能修复呢？

在网上找了一下，发现有专业的数据恢复公司，能恢复这种错误，从文章中提到的信息来看，应该通过直接构造损坏的页面来修复的。

由于这种情况比较难重现，所以这里模拟当某个数据页的page header损坏时，如何手动修复这个数据页，其实就是一个复制粘帖的过程。

1、先创建一个数据库，创建表，插入数据：

create database w
go

use w
go


if OBJECT_ID('test') is not null
 drop table test

select * into test
from sys.objects
go


insert into test
select * 
from test

3、本来通过dbcc writelog来修改数据，但是应该是没有修改好。

dbcc writepage的语法为：

dbcc writepage 
({ dbid,'dbname' }, fileid, pageid, offset, length, data)

--生成96个字节的数据
select '0x'+replicate('00',96)

dbcc writepage('w',1,310,0,96,
0x000000000000000000000000000000000000000
00000000000000000000000000000000000000000
00000000000000000000000000000000000000000
00000000000000000000000000000000000000000
000000000000000000000000000000)
/*
消息 39，级别 16，状态 5，第 1 行
表错误: 对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID 0 (类型为 Unknown)，页 (0:0)。测试(m_headerVersion == HEADER_7_0)失败。值为 0 和 1。
消息 39，级别 16，状态 6，第 1 行
表错误: 对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID 0 (类型为 Unknown)，页 (0:0)。测试((m_type >= DATA_PAGE && m_type <= UNDOFILE_HEADER_PAGE) || (m_type == UNKNOWN_PAGE && level == BASIC_HEADER))失败。值为 0 和 0。
消息 39，级别 16，状态 7，第 1 行
表错误: 对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID 0 (类型为 Unknown)，页 (0:0)。测试(m_freeData >= PageHeaderOverhead () && m_freeData <= (UINT)PAGESIZE - m_slotCnt * sizeof (Slot))失败。值为 0 和 8192。
DBCC 执行完毕。如果 DBCC 

select 8*1024*310 as '310页在文件中的物理偏移',
 CAST(8*1024*310 as varbinary) '转化为16进制'
/*
310页在文件中的物理偏移	转化为16进制
2539520	0x0026C000
*/

4、重新附加这个数据库

dbcc checkdb(w)
/*
消息 09，级别 16，状态 1，第 1 行
表错误: 对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID 0 (类型为 Unknown)，页 ID (1:310) 在其页头中包含错误的页 ID。页头中的 PageId = (0:0)。
CHECKDB 发现有 0 个分配错误和 1 个一致性错误与任何单个的对象都没有关联。

消息 28，级别 16，状态 1，第 1 行
对象 ID 981578535，索引 ID 0，分区 ID 720575940310976，分配单元 ID 72057594042580992 (类型为 In-row data): 无法处理页 (1:310)。有关详细信息，请参阅其他错误消息。

CHECKDB 在数据库 'w' 中发现 0 个分配错误和 2 个一致性错误。
对于由 DBCC CHECKDB (w)发现的错误，repair_allow_data_loss 是最低的修复级别。
DBCC 执行完毕。如果 DBCC 

6、再次附加数据库，就可以查询了。

不过，使用repair_allow_data_loss也可以恢复。