none
SQL 2000中,页的 slot 位置是如何计算的? RRS feed

  • 问题

  • 在 SQL Server 2000 中,对比文件和 DBCC PAGE 的数据,发现两者不一致,DBCC PAGE 的结果看起来是对的,不知道 DBCC PAGE 是按照什么样的处理对数据做修正的

    版本:Microsoft SQL Server  2000 - 8.00.2039 (Intel X86) 

    执行下面的 SQL 创建测试库,并得到 PAGE 0 的数据

    create database db_test
    go
    DBCC TRACEON (3604); 
    DBCC PAGE ('db_test', 1, 0, 2);
    go
    select * from db_test..sysfiles where fileid = 1
    alter database db_test set offline
    

    DBCC PAGE 得到的页面数据最后一行值如下,即 slot 0的偏移位置是 0x00f3:

    805F1FF0:  01000000 301f0000 b8005880 0000f300  ....0.....X.....

    但查询文件中的 slot 0 偏移位置(参考如下的 Powershell脚本),则是 0x01f3

    # $file 这个变量的文件名用上面查粜的文件名(filename列值)替换
    $file = 'C:\Program Files (x86)\Microsoft SQL Server\MSSQL\data\db_test.mdf'
    $page_id = 0
    $page = Get-Content $file -Encoding Byte -ReadCount 8192 |Select -First 1 -Skip $page_id
    $slots = [BitConverter]::ToUInt16($page, 22)
    for($i=1; $i -le $slots; $i++){ '{0:x2}{1:x2}' -F $page[(8192-$i),(8191-$i)] }
    

    DBCC PAGE 和 文件中存储的差异似乎也不是固定的差值,在这个链接中有一个损坏的 SQL 2000 的数据文件

    https://pan.baidu.com/s/15WzgcJ0SvZi2T2Oo9-VhPQ

    通过文件替换的方式,可以附加,并且通过 DBCC PAGE 可以读取到页的信息,在这个文件中,DBCC PAGE 得到 PAGE 0 的 slot 位置是 0x07ef,但直接查文件得到是 0x05ef,更奇怪的变长列的偏移,DBCC PAGE 得到的是:

    806A07E0:  9effb622 10b54aba 78ac8163 86c05f30  ..."..J.x..c.._0
    806A07F0:  00080000 00000017 00000000 16004b00  ..............K.

    也就是第1列的偏移是 0x004b

    而查文件得到的是这个,也就是第1个变长列偏移是 0x014b

    9e ff b6 22 10 b5 4a ba 78 ac 81 63 86 c0 5f 30
    00 08 00 00 00 00 00 17 00 00 00 00 16 00 4b 01


    2019年1月29日 1:52

全部回复

  • Hi zjcxc.邹建,

    DBCC Page获取的数据是SQL Server加载到内存里的页的memory dump,SQL Server在加载数据页的时候应该是进行了处理的,但是目前未找到公开资料表明是如何进行处理的。

    Best Regards,

    Teige


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    2019年1月30日 3:18
    版主