剖析SQLSERVER2005的页面结构--行类型篇一

来源：互联网发布：淘宝直播管理规范编辑：程序博客网时间：2024/06/05 16:29

剖析SQLSERVER2005的页面结构

行类型篇一

行(和我平常说的表的记录行有点差别哦，注意理解)简单的可理解为数据库物理存储的表、索引及其它类型的数据的基本单元。当然行结构远不止如下说明的那么简单，更深入的有待再度剖析，比如打开行版本后slot记录就会多出14个字节的xsn。

行记录是表里的数据，记录着表的内容。反之也就是表的记录是以数据行的形式保存在数据库的页面上。它一般是堆表的行或索引的叶级行，显然的是它一定保存着行的所有列数据，在这儿我们得注意一下，这个所有的列包含两层意思，一就是列的数据，另外可能是行溢出数据的指针。指针的情况又分为两种可能：一是使用了LOB数据类型，另一个是非LOB类型存储在超行最大8060限制时。这些不在此篇讨论的范围，一带而过。

关于如何查看页面内容的方法我在 SQL2005中的事务与锁定（九）一文有详细的说明，下面为了便于说明先写一个测试用例：

create table testtb(id int identity(1,1),col char(985))

insert into testtb

select REPLICATE('a',5) union all

select REPLICATE('b',5) union all

select REPLICATE('c',5) union all

select REPLICATE('d',5) union all

select REPLICATE('e',5) union all

select REPLICATE('f',5) union all

select REPLICATE('g',5) union all

select REPLICATE('h',5) union all

select REPLICATE('i',985) union all

select REPLICATE('j',985)

alter table testtb

alter column col char(1000) --

dbcc ind(testcsdn,testtb,-1)--220 221 232

dbcc traceon(3604)

dbcc page(testcsdn,1,220,1)

DATA:

Slot 0, Offset 0x60, Length 9, DumpStyle BYTE

Record Type = FORWARDING_STUB Record Attributes =

Memory Dump @0x4431C060

0000000: 04dd0000 00010002 00†††††††††††††††††.........

Slot 1, Offset 0x69, Length 1996, DumpStyle BYTE

Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP

Memory Dump @0x4431C069

......

Slot 2, Offset 0x835, Length 9, DumpStyle BYTE

Record Type = FORWARDING_STUB Record Attributes =

Memory Dump @0x4431C835

......

000007C0: 20202020 20202020 200300f8 †††††††††† ...

DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。

dbcc page(testcsdn,1,221,1)

PAGE: (1:221)

DATA:

Slot 0, Offset 0x1014, Length 1996, DumpStyle BYTE

Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP

Memory Dump @0x3432D014

00000000: 1000c907 09000000 69696969 69696969 †.......iiiiiiii

......

Slot 2, Offset 0x60, Length 2010, DumpStyle BYTE

Record Type = FORWARDED_RECORD Record Attributes = NULL_BITMAP VARIABLE_COLUMNS

Memory Dump @0x3432C060

00000000: 3200c907 01000000 61616161 61202020 †.......aaaaa

上例只是出现了行类型的一部分(PRIMARY_RECORD、FORWARDING_STUB 、FORWARDED_RECORD)，下面我们来说说行的类型有哪几类：

1、PRIMARY_RECORD 主记录

当Record Type = PRIMARY_RECORD时表明当前记录是主记录，我们随便找一个主记录行前四个字节：1000c907 ，状态位A为：0x10 ,bit1-3位全是0 ，当全是0时代表当前行是主记录。行的基本结构我在SQL2005中的事务与锁定（九）一文有详细介绍，在这儿不再细说。

Record Type

行前四个字节

状态位A

bit1-3

PRIMARY_RECORD

1000c907

0x10

2、FORWARDING_STUB 转移根

当Record Type = FORWARDING_STUB时表明当前记录是行转移后留下的一条转移根信息。在这儿我们应该清楚一点这只会发生在堆表，因为在当前位置已经无法保存数据，所以搬移当前位置，只是在当前位置留一个类指针的数据，指向最终搬向的数据。从技术上来说，它也避免SQLSERVER误把数据存在原来的位置，但是也增加了select的IO量，虽然我们可用使用聚集索引来回避，但是这种性能上的得失全是在于DBA自己权衡。请看如下页面信息片断：

Slot 0, Offset 0x60, Length 9, DumpStyle BYTE

Record Type = FORWARDING_STUB Record Attributes =

Memory Dump @0x4431C060

0000000: 04dd0000 00010002 00†††††††††††††††††.........

我们发现这一行只有9个字节的长度，细一看和我在SQL2005中的事务与锁定（九）介绍的基本行结构有了差别，那这9个字节代表什么意思呢，这9个字节代表意思如下表：

状态位

文件号+页面ID

SLOT号

dd0000000100

02 00

在上表中状态位04和以前介绍行的基本信息时的状态位A意义相同，bit1-3为1代表当前记录行是转移根，那这后面的文件号+页面ID+slot号,它最终指向数据搬到的地点，如何和实现关联起来呢？下面请看我的转换SQL语句(我已经封装成存储过程sp_us_FPSinfo方便大家调用)：

---------------------------------------------------------------------

-- Author : HappyFlyStone

-- Date : 2009-11-30

-- Version: Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)

-- Apr 14 2006 01:12:25

-- Enterprise Edition on Windows NT 5.2 (Build 3790: SP2)

-- 转载注明出处及相关信息

---------------------------------------------------------------------

CREATE PROC sp_us_FPSinfo

@FORWARDING_STUB BINARY(8)

SELECT

CAST(

CONVERT(INT,SUBSTRING(@FORWARDING_STUB,6,1)) * POWER(2,8)

+ CONVERT(INT,SUBSTRING(@FORWARDING_STUB,5,1))

AS VARCHAR)+' : ' --File_num

+CAST(

(CONVERT(INT,SUBSTRING(@FORWARDING_STUB,4,1)) * POWER(2,24))

+ (CONVERT(INT,SUBSTRING(@FORWARDING_STUB,3,1)) * POWER(2,16))

+ (CONVERT(INT,SUBSTRING(@FORWARDING_STUB,2,1)) * POWER(2,8 ))

+ (CONVERT(INT,SUBSTRING(@FORWARDING_STUB,1,1))) AS VARCHAR)

+' : ' --Page_id

+CAST(CAST(SUBSTRING(@FORWARDING_STUB,8,1) * POWER(2,8 ) +

+ SUBSTRING(@FORWARDING_STUB,7,1) AS INT ) AS VARCHAR)

AS 'FILE_NUM:PAGE_ID:SLOT_ID'

EXEC sp_us_FPSinfo 0xDD00000001000200 --

DROP PROC sp_us_FPSinfo

FILE_NUM:PAGE_ID:SLOT

--------------------------

1 : 221 : 2

(1 行受影响)

这个转换的结果表明本来在当前位置的记录已经转移到文件号为1页面为221的slot为2的记录，在上面一开始我们查看221页面的信息，的确可以对应上，在这儿我们介绍一下上面的这一条记录转换的原因，因为我们一开始定义的表结构并插入记录在页面220的第一条记录是’aaaaa’,后因为修改列长，造成页面记录转换，根据上面的转换我们在页面221的第二条记录的确看到’aaaaa’的影子。

Record Type

状态位

bit1-3

FORWARDING_STUB

0x04

3、FORWARDED_RECORD 转移记录

当Record Type = FORWARDED_RECORD时表明当前是一条转换过来的记录。这正好和第二种类型相对，就是转移根指向的记录行，这个类型的记录行与基本行的结构还是有点差别的，前一部分差不多，只是最后有点不同。

状态A

状态B

定长部分长度

定长数据

定长列数

NULL位图

不明待查

file_page_slot

(可用上面的过程转为转译，找到FORWARDING_STUB)

c907

01000000 6161...... 20

0300

0100da87 0004

dc00 00000100 0000

3-有变长列及NULL位图

2-1表示转移记录

未用

1993

DATA

3列

长度：ceiling(3/8)

最后三位为0

？？？？

(暂时只发现只要转移过，都是这个值)

FILE_NUM:PAGE_ID:SLOT

--------------------

1 : 220 : 0

状态A的bit1-3 为 1 表明当前记录行为转移根所指向的转移记录。它和主数据记录有差别就是在最后多了14个字节的数据，最后的8位通过我以上的过程(sp_us_FPSinfo)，很明显的得到了转移根所有的文件页面及slot号。

4、INDEX_RECORD 索引记录

我们先来生成一条索引记录，在对上表创建一个索引，脚本如下：

drop table testtb

create table testtb(id int ,pid int,col char(10))

insert into testtb select 9,5,'a'

insert into testtb select 3,4,'b'

insert into testtb select 4,3,'c'

insert into testtb select 5,2,'d'

insert into testtb select 6,1,'e'

go--clustered

create index idx_testtb_id on testtb(pid,id)

dbcc traceon(3604)

dbcc ind(testcsdn,testtb,-1)--> 230

dbcc page(testcsdn,1,232,1)

Slot 0, Offset 0x60, Length 20, DumpStyle BYTE

Record Type = INDEX_RECORD Record Attributes = NULL_BITMAP

Memory Dump @0x446AC060

00000000: 16010000 00060000 00dc0000 00010004 †................

00000010: 000300f8 ††††††††††††††††††††††††††††....

索引行有别于基本行的格式大体如下：

状态位

数据

文件号+页面号+槽号

列数(包括地址)

NULL位图

010000 00060000 00

dc0000 00010004 00

0300

Bit4为1代表有NULL位图

Bit3-1为3代表是一条索引记录

Data

EXEC sp_us_FPSinfo 0xdc00000001000400

数据两列加上位置，共三列

FILE_NUM:PAGE_ID:SLOT_ID

--------------------------

1 : 220 : 0

(未完，待续)

谢谢大家关注我的blog!!