先执行一下以下SQL语句，我的测试环境为SQL2005
dbcc traceon(3604)
go
dbcc page(master,1,0,2)
可以看到MDF文件的一些物理结构信息，其中包括重要的头96个字节。也就是第一个页面的文件头。
........
PAGE HEADER:
Page @0x03FA0000
m_pageId = (1:0) m_headerVersion = 1 m_type = 15
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8
m_objId (AllocUnitId.idObj) = 99 m_indexId (AllocUnitId.idInd) = 0 Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0 Metadata: IndexId = 0 Metadata: ObjectId = 99
m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 0
m_slotCnt = 1 m_freeCnt = 7937 m_freeData = 3059
m_reservedCnt = 0 m_lsn = (149:448:1) m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = -1073741694
........
DATA:
Memory Dump @0x62FEC000
62FEC000: 010f0000 08000000 00000000 00000000 †................
62FEC010: 00000000 00000100 63000000 011ff30b †........c.......
62FEC020: 00000000 01000000 95000000 c0010000 †................
62FEC030: 01000000 00000000 00000000 820000c0 †................
62FEC040: 00000000 00000000 00000000 00000000 †................
62FEC050: 00000000 00000000 00000000 00000000 †................
以上蓝色的文字就是文件头的一些信息。如果这些信息损坏将会造成严重的后果。
经过简单的逐个字节分析，中间借助了windows计算器和c#的BitConverter.GetBytes函数。得出了如下文件结构图，其中每行4个字节，一共分析了文件头的前64个字节。
| 00:0F | m_headerVersion | m_type | m_typeFlagBits | m_level |
| m_flagBits | m_indexId | |||
| m_prevPage(2) | ||||
| m_prevPage(1) | pminlen | |||
| 10:1F | m_nextPage(2) | |||
| m_nextPage(1) | m_slotCnt | |||
| AllocUnitId.idObj | ||||
| m_freeCnt | m_freeData | |||
| 20:2F | m_pageId（2） | |||
| m_pageId（1） | m_reservedCnt | |||
| m_lsn(1) | ||||
| m_lsn(2) | ||||
| 30:3F | m_lsn(3) | m_xactReserved | ||
| m_xdesId(2) | ||||
| m_xdesId(1) | m_ghostRecCnt | |||
| m_tornBits |
在数据库的头96个字节中第0x40开始直道0x5F应该都是0。
我发现只有测试页的m_pageId 的冒号前面的数字不为1时才在0x40到0x5f写入数据。但是具体代表什么还没有看出来。
姑且认为数据库第一个页面的0x00-0x3f就如上图所示，0x40-0x5f都为0（不正确的话请纠正一下）
这张图有什么用呢，如果你理解了上述参数的意义，用二进制编辑器打开一个头文件损坏的mdf文件就有可能恢复这个已经损坏的数据库。
偶不是dba也不是专业恢复数据的，只是个普通的开发人员，怎么恢复还请有经验人士补充一下。
有情提醒，这些东西非常危险，请不要随意测试，最好找一个没用的数据库来研究。