原文首发于it168专稿,链接见/a/0916/1104/000001104500.shtml
谈到GAM和SGAM,我们不得不从数据库的页和区说起。一个数据库由用户定义的空间构成,这些空间用来永久存储用户对象,例如数据库管理信息、表和索引。这些空间被分配在一个或多个操作系统文件中。
当我们创建一个数据库的时候,例如以缺省的方式CREATE DATABASE TESTDB,SQLServer自动帮我们创建好如下两个数据库文件。
这两个数据文件是实实在在的操作系统文件,其中一个是叫行数据文件,用来存储数据库的各种对象,另外一个是日志文件,从来记录数据变化的过程。
从逻辑角度而言,数据库的最小存储单位为页即8kb。
数据库被分成若干逻辑页面(每个页面8KB),并且在每个文件中,所有页面都被连续地从0到x编号,其中x是由文件的大小决定的。我们可以通过指定一个 数据库ID、一个文件ID、一个页码来引用任何一个数据页。每个数据页则用来存储表和索引,以及相关的数据库管理信息。
我们顺着上面数据文件的路径可以找到该文件,观察一下新建的数据文件的大小为:
2.18 MB (2,293,760 字节)=2,293,760b/8kb=280个页面=35个区
数据库进行空间管理的最小单位为区(extents)。
一个区由8个逻辑上连续的页面组成(64KB的空间)。为了能够更有效地分配空间,SQL Server 不会为少量的数据向数据表分配整区的空间。SQL Server 有两种类型的区。
统一类型的区 这些区为单个对象所有,区中所有的8个数据页只能被所属对象使用。
混合类型的区 这些区能为最多8个对象共享。
SQL Server为新的表或索引从混合类型的区中分配页面。当该表或索引增长到8个页面时,以后所有的分配都使用统一类型的区。
当一张表或一个索引需要更多的空间时,SQL Server需要找到能够用来分配的空间。如果该表或索引整体仍然少于8个页面,SQL Server必须找到能够用来分配的混合类型区构成的空间。如果表或索引有8个页面或更大,SQL Server必须找到一个自由的统一类型的区。
SQL Server使用两种特殊类型的页面来记录哪些区已经被分配出去了,哪些类型(混合类型或统一类型)的区可供使用:
全局分配映射(Global Allocation Map,GAM)页面 这些页面记录了哪些区已经被分配并用作何种用途。一个GAM页面在它所覆盖空间里针对每一个区都有一个数据位。如果数据位为0,那么对应的区正在使用;如 果该数据位为1,那么该区为自由区。一个GAM页面除了页面头部和其他一些需要记入的开销大概有8 000字节或者说64 000位空间可用,所以每个GAM页面可以覆盖64 000个区,也就是大约4GB的数据。这意味着一个文件的每4GB空间对应一个GAM页面。
共享全局分配映射(Shared Global Allocation Map,SGAM)页面 这些页面记录了哪些区当前被用作混合类型的区,并且这些区需含有至少一个未使用的页面。就像一个GAM页面,每一个SGAM页面覆盖了大约64 000个区,也就是大约4GB的数据。一个SGAM页面在它所覆盖空间里针对每一个区都有一个数据位。如果数据位为1,那么对应的被使用的区为混合类型, 并且该区有一些自由页面;如果数据位为0,那么对应的区不是一个混合类型的区,或者虽然是一个混合类型的区,但是所有的页面都已被使用了。
表4-2显示了基于每一个区当前的使用情况,在GAM和SGAM中该区所对应的比特位模式。
如果SQL Server需要找到一个新的完全没有使用的区,那么它可以使用任何一个在GAM页面中对应的比特位值为1的区。如果SQL Server需要找到一个有着可用空间(有一个或多个自由页面)的混合类型的区,那么它可以寻找一个对应的GAM中的值为0、SGAM中的值为1的区。如 果不存在有可用空间的混合类型的区,SQL Server会使用GAM页面来寻找一个全新的区并将其分配为混合类型的区,然后使用该区中的一页。如果根本没有自由区,那么这个文件已经满了。
SQL Server能够迅速地锁定一个文件中的GAM页面,因为它总是位于任何数据库文件的第三页上(页码为2)。SGAM页面是在第四页上(页码为3)。下一 个GAM页面出现在第一个GAM页面(页码为2)以后的每511 230个页面中,并且下一个SGAM页面出现在第一个SGAM页面(页码为3)以后的每511 230个页面中。每一个数据库文件的页码为0的页面是文件头页面,并且每个文件仅有一页。页码0是头文件页,页码1是页面自由空间页(Page Free Space,PFS)。
在SQLServer的每一个数据库中的前八页顺序都是固定的。
除了第9页为数据库的BOOT页以外,从第8页到第173页为SQLServer内部系统表的相关存储信息,然后从第174页到第279页为未分配页面。因为第一页从0开始,所以刚好280页,即和我们看到的数据库数据文件的大小完全相等。
以下截图是通过SQLServer的Internals Viewer插件看到的整体页面结构,该插件是从网站下载的,分为不同的.net版本。
备注:TESTDB为新创建的空数据库,没有任何用户自定义对象,直到有建表脚本为止;
关于数据库页类型如下所示:
实际上SQLServer还包括一些未公开的页面类型,例如type 19,type 14等等。
本章我们主要介绍GAM页和SGAM页,其他页面类型会稍后介绍。
那么如何查看页面信息呢,从SQLServer2000起便开始提供了一个读取数据页结构的命令DBCC Page。该命令为非文档化的命令,具体如下:
DBCC Page ({dbid|dbname},filenum,pagenum[,printopt])
具体参数描述如下:
dbid 包含页面的数据库ID
dbname 包含页面的数据库的名称
filenum 包含页面的文件编号
pagenum 文件内的页面
printopt 可选的输出选项;选用其中一个值:
0:默认值,输出缓冲区的标题和页面标题
1:输出缓冲区的标题、页面标题(分别输出每一行),以及行偏移量表
2:输出缓冲区的标题、页面标题(整体输出页面),以及行偏移量表
3:输出缓冲区的标题、页面标题(分别输出每一行),以及行偏移量表;每一行后跟分别列出的它的列值
如果要想看到这些输出的结果,还需要设置DBCC TRACEON(3604)。
如前文所述,GAM页一定存在于该数据库的第二个页面,SGAM页则一定存在于该数据库的第三个页面;而每一个数据库都会存在文件编号为1的数据库文件,所以我们执行以下命令即可。
DBCC TRACEON(3604)
DBCC PAGE(TESTDB,1,2,1)—查看GAM页信息
DBCC PAGE(TESTDB,1,3,1)—查看SGAM页信息
DBCC PAGE(TESTDB,1,2,2)—查看GAM页信息和整体输出页面
DBCC PAGE(TESTDB,1,3,2)—查看SGAM页信息和整体输出页面
DBCC PAGE(TESTDB,1,2,3)—查看GAM页信息及相应列值
DBCC PAGE(TESTDB,1,3,3)—查看SGAM页信息及相应列值
DBCC PAGE(TESTDB,1,2,1) WITH TABLERESULTS—以表格形式查看SGAM页信息及相应列值
DBCC PAGE(TESTDB,1,3,1) WITH TABLERESULTS—以表格形式查看SGAM页信息及相应列值
我们可以看到一个完整的页面分为四个部分;BUFFER、PAGE HEADER、DATA和OFFSET TABLE。
让我们首先从GAM页开始看起:
BUFFER部分:
显示给定页面的缓冲信息,是内存中的结构,用于管理页面,该信息仅当该页面处于内存时才有意义。关于这个部分我们知之甚少,基本上无法找到相关材料。
PAGE HEADER部分:
PAGE HEADER部分显示的是该页面上的所有报头字段的数据
PAGE HEADER这部分内容只有通过DBCC PAGE(TESTDB,1,2,2)即整体输出页面才能够展现;通过与上面表格的对照,我们勉强能识别一些相关存储信息;当这部分缺乏官方文档的支持,为了避免无谓的猜测,所以暂时就不做深入探讨了。
DATA 部分
DATA部分一般分为若干插槽号(Slot),如果是数据页或索引页的话,可以理解为一行记录,SQLServer通过文件号+页面号+插槽号用来唯一标识表中的每一条记录。但在GAM页中我们可以把Slot 0理解为GAM页的保留页,共计94个字节。
从第194个字节开始(页面总是从第0个字节开始的),到第196个字节,这三个字节代表已分配的分区的情况。即0000C0。
我们再来看一下DBCC PAGE(TESTDB,1,2,3)的执行结果。
上面显示从第1页到第168页已分配,而第176页到272页未分配,和DBCC PAGE(TESTDB,1,2,2)显示的194个页面似乎有些矛盾,实际上是不矛盾的。如前文所述,GAM对未使用的分区标识为0,而对已分配的分区标识为1
1个分区=64页,因为前128个页面均已分配,所以前两个字节为00 00
从第128个页面起到第175个页面也均已分配,实际上为6个区为0也就是说连续6个bit为0,一个字节为8个bit,最后两个bit为11,所以该字节为0000 0011,在此需要反转一下相关二进制位;反转之后为1100 0000即为C0。
最后让我们用Internals Viewer插件看一下GAM页的全貌吧。
SGAM页面
PAGE: (1:3)
BUFFER:
BUF @0x0358A7F4
bpage = 0x062AE000 bhash = 0x00000000bpageno = (1:3)
bdbid = 8breferences = 3 bUse1 = 14428
bstat = 0xc00009 blog = 0x21212159bnext = 0x00000000
PAGE HEADER:
Page @0x062AE000
m_pageId = (1:3) m_headerVersion = 1 m_type = 9
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x200
m_objId (AllocUnitId.idObj)=99 m_indexId (AllocUnitId.idInd)=0 Metadata: AllocUnitId=6488064
Metadata: PartitionId = 0Metadata: IndexId = 0 Metadata: ObjectId = 99
m_prevPage = (0:0) m_nextPage = (0:0)pminlen = 90
m_slotCnt = 2m_freeCnt = 6 m_freeData = 8182
m_reservedCnt = 0m_lsn = (18:435:5)m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 177043542
Allocation Status
GAM (1:2)=ALLOCATEDSGAM (1:3)=NOT ALLOCATEDPFS(1:1)=0x44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED ML (1:7) = NOT MIN_LOGGED
DATA:
Slot 0, Offset 0x60, Length 94, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes =
Memory Dump @0x4F32C060
00000000: 00005e00 00000000 00000000 00000000 ?..^.............
00000010: 00000000 00000000 00000000 00000000 ?................
00000020: 00000000 00000000 00000000 00000000 ?................
00000030: 00000000 00000000 00000000 00000000 ?................
00000040: 00000000 00000000 00000000 00000000 ?................
00000050: 00000000 00000000 00000000 0000??????..............
Slot 1, Offset 0xbe, Length 7992, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes =
Memory Dump @0x4F32C0BE
00000000: 0000381f 20ee2000 00000000 00000000 ?..8. . .........
00000010: 00000000 00000000 00000000 00000000 ?................
00001F30: 00000000 00000000 ???????????????????........
以下为DBCC PAGE(TESTDB,1,3,3)得到的相关信息,有兴趣的可以和20ee20做一下对比。
(1:0)- (1:32) = NOT ALLOCATED
(1:40) -= ALLOCATED
(1:48) - (1:64) = NOT ALLOCATED
(1:72) - (1:88) = ALLOCATED
(1:96) -= NOT ALLOCATED
(1:104)- (1:120)= ALLOCATED
(1:128)- (1:160)= NOT ALLOCATED
(1:168)-= ALLOCATED
(1:176)- (1:272)= NOT ALLOCATED
最后让我们用Internals Viewer插件看一下SGAM页的全貌吧。
总结一下,关于GAM和SGAM页比较困难的地方:
1、 关于GAM和SGAM页中的BUFFER信息基本无法理解,也找不到相关材料。
2、 PAGE HEADER的部分信息和Slot 0中的一部分信息,也无法找到相关材料。
3、 SGAM页中的NOT ALLOCATED实际上是统一类型区或者已使用完的混合类型的区,而ALLOCATED实际上为含有自由页面的混合区。
4、 GAM页中0代表已分配,1代表自由区;和一般的标志位的含义刚好相反。
5、 GAM和SGAM实际上只分配了280个页面,即35个区;显示出来的数据内容虽然很多,但后面的分区信息实际上是不存在的。
6、 GAM和SGAM通过DBCC的printopt为3的属性显示出来的页面分配信息看似是断号的。
7、 GAM和SGAM的区信息的字节是通过二级制反转得到的。
GAM和SGAM页的总的大小为8192个字节;文件头为96个字节,slot 0为94个字节,slot 1的头部的系统信息为4个字节,尾部的系统信息为10个字节,所以有效存储应为7988个字节,63904个区,511230个页;事实上当数据文件超过 约4G的时候,我们将能在第511232页、 第511233页分别找到其对应的GAM、SGAM页面。
如果觉得《SQL Server 存储结构之GAM SGAM》对你有帮助,请点赞、收藏,并留下你的观点哦!