SQLserver数据文件(MDF)的页面文件头结构剖析

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个字节。

在数据库的头96个字节中第0x40开始直道0x5F应该都是0。

我发现只有测试页的m_pageId 的冒号前面的数字不为1时才在0x40到0x5f写入数据。但是具体代表什么还没有看出来。

姑且认为数据库第一个页面的0x00-0x3f就如上图所示，0x40-0x5f都为0（不正确的话请纠正一下）

这张图有什么用呢，如果你理解了上述参数的意义，用二进制编辑器打开一个头文件损坏的mdf文件就有可能恢复这个已经损坏的数据库。

偶不是dba也不是专业恢复数据的，只是个普通的开发人员，怎么恢复还请有经验人士补充一下。

有情提醒，这些东西非常危险，请不要随意测试，最好找一个没用的数据库来研究。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!