SQL Server頁(yè)類型匯總+疑問(wèn)匯總

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

查詢結(jié)果：

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

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

我搜遍了google也沒(méi)有找到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，是在“大容量日志”模式下，記錄自上次備份以來(lái)哪些區(qū)被更改過(guò)，該頁(yè)第一個(gè)位置總是在每個(gè)文件的第7頁(yè)上，我們折回上面第一個(gè)查詢時(shí)的第三行，即PageType是ML_MAP_PAGE的那行，

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

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

我們將PageID7帶入DBCC PAGE:

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

好吧，我只能說(shuō)，是我曲解了人家字面的意思，原來(lái)：

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

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

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