SQL Server中包含多種不同類型的頁，來滿足數(shù)據(jù)存儲(chǔ)的需求。不管是什么類型的頁，它們的存儲(chǔ)結(jié)構(gòu)都是相同的。每個(gè)數(shù)據(jù)文件都包含相當(dāng)數(shù)量的由8KB組成的頁，即每頁有8192bytes可用，每頁都有96byte用于頁頭的存儲(chǔ)，剩下的空間

才用來存儲(chǔ)實(shí)際的數(shù)據(jù)，在頁的最后是數(shù)據(jù)行偏移數(shù)組，也可以叫“頁槽”數(shù)組，我們可以把一個(gè)頁看做是有一個(gè)個(gè)方格的書櫥，哪行數(shù)據(jù)占用了哪個(gè)槽，都在頁尾的位置進(jìn)行標(biāo)示，并且頁尾數(shù)組的寫入順序是倒敘的，這樣就可以有效的利用頁空間。

由此可以預(yù)見，頁面上的“槽”并不一定是有序存放的，當(dāng)有新的ID進(jìn)來，并且該ID位于該頁的最大ID和最小ID之間時(shí)（假設(shè)是以ID進(jìn)行排序的葉子頁），那么該ID數(shù)據(jù)行則直接插入到已經(jīng)存在的數(shù)據(jù)行的后面即可，當(dāng)有查詢需要檢索該ID所在的行時(shí)，

數(shù)據(jù)庫引擎從索引頁找到該“葉子”頁，將該頁全部加載到內(nèi)存中，通過頁尾的行偏移數(shù)組找到對應(yīng)的行。頁尾數(shù)組的記錄大小存儲(chǔ)在頁頭里，數(shù)組里面每一個(gè)關(guān)于“頁槽”的記錄占用空間為2bytes。

據(jù)我所知，SQL Server數(shù)據(jù)文件共有14種頁類型：

類型1——數(shù)據(jù)頁(Data Page)：堆中的數(shù)據(jù)頁聚集索引中的“葉子”頁在數(shù)據(jù)文件中的位置是隨機(jī)的DBCC PAGE 中m_type=1

類型2——索引頁(Index Page)：

非聚集索引非“葉子”級聚集索引在數(shù)據(jù)文件中的位置是隨機(jī)的DBCC PAGE 中m_type=2

類型3——文本混合頁(Text Mixed Page)：

較短長度的LOB數(shù)據(jù)類型，多種類型，多行存儲(chǔ)在數(shù)據(jù)文件中的位置是隨機(jī)的DBCC PAGE 中m_type=3

類型4——文本頁(Text Tree Page)：

存儲(chǔ)單個(gè)LOB行在數(shù)據(jù)文件中的位置是隨機(jī)的DBCC PAGE 中m_type=4

類型5——排序頁(Sort Page)：

進(jìn)行排序操作時(shí)的臨時(shí)頁常見于TempDB中，在用戶數(shù)據(jù)中進(jìn)行“ONLINE"操作時(shí)也可見(例如：聯(lián)機(jī)創(chuàng)建索引未指定SORT_IN_TEMPDB選項(xiàng)時(shí))在數(shù)據(jù)文件中的位置是隨機(jī)的DBCC PAGE 中m_type=19

類型6——全局分配映射頁(GAM Page)：

Global Allocation Map，記錄已分配的非共享（混合）區(qū)是否已被使用每個(gè)區(qū)占用一個(gè)bit位，如果該值為1，說明該區(qū)可以使用，0則說明已被使用（但是并不一定存儲(chǔ)空間已滿）第一個(gè)GAM頁總是存儲(chǔ)在每個(gè)數(shù)據(jù)文件PageID為2的頁上DBCC PAGE 中m_type=8

類型7——共享全局分配映射頁(SGAM Page)：

Shared Global Allocation Map，記錄每一個(gè)共享（混合）區(qū)是否已被使用每個(gè)區(qū)占用一個(gè)bit位，如果該值為1，說明該區(qū)有空閑的存儲(chǔ)空間，0則說明區(qū)已滿第一個(gè)SGAM頁總是存儲(chǔ)在每個(gè)數(shù)據(jù)文件PageID為3的頁上DBCC PAGE 中m_type=9

類型8——索引分配映射頁(IAM Page)：

Index Allocation Map，記錄GAM頁之間堆表或者索引的區(qū)分配在數(shù)據(jù)文件中的位置是隨機(jī)的DBCC PAGE 中m_type=10

類型9——空閑空間跟蹤頁(PFS Page)：

Page Free Space，跟蹤頁的可用空間。
第一個(gè)PFS頁總是存儲(chǔ)在每個(gè)數(shù)據(jù)文件PageID為1的頁上DBCC PAGE 中m_type=11

類型10——啟動(dòng)頁(Boot Page)：

存儲(chǔ)所在數(shù)據(jù)庫范圍的信息僅在每個(gè)數(shù)據(jù)庫文件(file)ID為1的PageID為9的頁上DBCC PAGE 中m_type=13

類型11——服務(wù)配置頁(Server Configuration Page)：

存儲(chǔ)了sys.configurations中返回結(jié)果中的部分信息該頁僅存在于master數(shù)據(jù)庫的文件ID為1PageID為10的頁上

類型12——文件頭頁(File Header Page)：

所在文件的信息總是存在于每個(gè)文件PageID為0的頁上DBCC PAGE 中m_type=15

類型13——差異更改映射(Differential Changed map)：

記錄GAM之間的每次全備或差異備份之后更改過的頁面第一個(gè)DCM頁面在每個(gè)數(shù)據(jù)文件PageID為6的頁上DBCC PAGE 中m_type=16

類型14——大容量更改映射(Bulk Change Map)：

記錄每個(gè)GAM之間上次備份之后大容量操作的更改第一個(gè)BCM頁面在每個(gè)數(shù)據(jù)文件PageID為7的頁上DBCC PAGE 中m_type=17

如下SQL可以查詢到你當(dāng)前的數(shù)據(jù)庫中的緩存的頁類型及數(shù)量：

結(jié)果如下圖所示：

按上面的數(shù)據(jù)類型介紹，我們很自然地認(rèn)為類型14——大容量更改映射(Bulk Change Map)就是圖示查詢結(jié)果中第10行BULK_OPERATION_PAGE

但是事實(shí)是嗎？我們將data_type=BULK_OPERATION_PAGE的記錄查出來：

查詢結(jié)果：

我們把查詢結(jié)果中的一個(gè)PageID帶入DBCC PAGE（其實(shí)這里已經(jīng)看出，這個(gè)pageID并不像上面說的第一個(gè)BCM頁面在每個(gè)數(shù)據(jù)文件PageID為7的頁上，它們是邏輯上連續(xù)的頁！

我們發(fā)現(xiàn)上面的m_type=20！

我搜遍了google也沒有找到m_type=20是什么記錄！

參考網(wǎng)址：http://www.sqlskills.com/BLOGS/PAUL/post/Inside-the-Storage-Engine-Anatomy-of-a-page.aspx

但是我們可以查到如下信息：

m_type=17的這個(gè)數(shù)據(jù)類型ML map page，是在“大容量日志”模式下，記錄自上次備份以來哪些區(qū)被更改過，該頁第一個(gè)位置總是在每個(gè)文件的第7頁上，我們折回上面第一個(gè)查詢時(shí)的第三行，即PageType是ML_MAP_PAGE的那行，

并將其帶入如下SQL查詢出pageID的記錄：

發(fā)現(xiàn)這才是傳說中的那個(gè)第一頁總是出現(xiàn)在每個(gè)文件第7頁的混蛋！

我們將PageID7帶入DBCC PAGE:

Oh,SHIT!這個(gè)的m_type是17！

好吧，我只能說，是我曲解了人家字面的意思，原來：

BCM ，大容量更改映射(Bulk Change Map)，在數(shù)據(jù)庫緩存中對應(yīng)的PageType竟然是ML_MAP_PAGE！Minimally-Logged Page！

而那個(gè)該死的BULK_OPERATION_PAGE(m_type=20)是什么東西，誰能告訴我？

另外那個(gè)UNLINKED_REORG_PAGE，應(yīng)該就是排序頁吧？

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。