SQL Server頁類型匯總+疑問匯總
SQL Server中包含多種不同類型的頁,來滿足數據存儲的需求。不管是什么類型的頁,它們的存儲結構都是相同的。每個數據文件都包含相當數量的由8KB組成的頁,即每頁有8192bytes可用,每頁都有96byte用于頁頭的存儲,剩下的空間
才用來存儲實際的數據,在頁的最后是數據行偏移數組,也可以叫“頁槽”數組,我們可以把一個頁看做是有一個個方格的書櫥,哪行數據占用了哪個槽,都在頁尾的位置進行標示,并且頁尾數組的寫入順序是倒敘的,這樣就可以有效的利用頁空間。
由此可以預見,頁面上的“槽”并不一定是有序存放的,當有新的ID進來,并且該ID位于該頁的最大ID和最小ID之間時(假設是以ID進行排序的葉子頁),那么該ID數據行則直接到已經存在的數據行的后面即可,當有查詢需要檢索該ID所在的行時,
數據庫引擎從索引頁找到該“葉子”頁,將該頁全部加載到內存中,通過頁尾的行偏移數組找到對應的行。頁尾數組的記錄大小存儲在頁頭里,數組里面每一個關于“頁槽”的記錄占用空間為2bytes。

據我所知,SQL Server數據文件共有14種頁類型:
類型1——數據頁(Data Page):堆中的數據頁聚集索引中的“葉子”頁在數據文件中的位置是隨機的DBCC PAGE 中m_type=1
類型2——索引頁(Index Page):
非聚集索引非“葉子”級聚集索引在數據文件中的位置是隨機的DBCC PAGE 中m_type=2
類型3——文本混合頁(Text Mixed Page):
較短長度的LOB數據類型,多種類型,多行存儲在數據文件中的位置是隨機的DBCC PAGE 中m_type=3
類型4——文本頁(Text Tree Page):
存儲單個LOB行在數據文件中的位置是隨機的DBCC PAGE 中m_type=4
類型5——排序頁(Sort Page):
進行排序操作時的臨時頁常見于TempDB中,在用戶數據中進行“ONLINE"操作時也可見(例如:聯機創(chuàng)建索引未指定SORT_IN_TEMPDB選項時)在數據文件中的位置是隨機的DBCC PAGE 中m_type=19
類型6——全局分配映射頁(GAM Page):
Global Allocation Map,記錄已分配的非共享(混合)區(qū)是否已被使用每個區(qū)占用一個bit位,如果該值為1,說明該區(qū)可以使用,0則說明已被使用(但是并不一定存儲空間已滿)第一個GAM頁總是存儲在每個數據文件PageID為2的頁上DBCC PAGE 中m_type=8
類型7——共享全局分配映射頁(SGAM Page):
Shared Global Allocation Map,記錄每一個共享(混合)區(qū)是否已被使用每個區(qū)占用一個bit位,如果該值為1,說明該區(qū)有空閑的存儲空間,0則說明區(qū)已滿第一個SGAM頁總是存儲在每個數據文件PageID為3的頁上DBCC PAGE 中m_type=9
類型8——索引分配映射頁(IAM Page):
Index Allocation Map,記錄GAM頁之間堆表或者索引的區(qū)分配在數據文件中的位置是隨機的DBCC PAGE 中m_type=10
類型9——空閑空間跟蹤頁(PFS Page):
Page Free Space,跟蹤頁的可用空間。
第一個PFS頁總是存儲在每個數據文件PageID為1的頁上DBCC PAGE 中m_type=11
類型10——啟動頁(Boot Page):
存儲所在數據庫范圍的信息僅在每個數據庫文件(file)ID為1的PageID為9的頁上DBCC PAGE 中m_type=13
類型11——服務配置頁(Server Configuration Page):
存儲了sys.configurations中返回結果中的部分信息該頁僅存在于master數據庫的文件ID為1PageID為10的頁上
類型12——文件頭頁(File Header Page):
所在文件的信息總是存在于每個文件PageID為0的頁上DBCC PAGE 中m_type=15
類型13——差異更改映射(Differential Changed map):
記錄GAM之間的每次全備或差異備份之后更改過的頁面第一個DCM頁面在每個數據文件PageID為6的頁上DBCC PAGE 中m_type=16
類型14——大容量更改映射(Bulk Change Map):
記錄每個GAM之間上次備份之后大容量操作的更改第一個BCM頁面在每個數據文件PageID為7的頁上DBCC PAGE 中m_type=17
如下SQL可以查詢到你當前的數據庫中的緩存的頁類型及數量:
結果如下圖所示:

按上面的數據類型介紹,我們很自然地認為類型14——大容量更改映射(Bulk Change Map)就是圖示查詢結果中第10行BULK_OPERATION_PAGE
但是事實是嗎?我們將data_type=BULK_OPERATION_PAGE的記錄查出來:
ORDER BY database_id,FILE_ID,page_id
查詢結果:

我們把查詢結果中的一個PageID帶入DBCC PAGE(其實這里已經看出,這個pageID并不像上面說的第一個BCM頁面在每個數據文件PageID為7的頁上,它們是邏輯上連續(xù)的頁!

我們發(fā)現上面的m_type=20!
我搜遍了google也沒有找到m_type=20是什么記錄!
參考網址:http://www.sqlskills.com/BLOGS/PAUL/post/Inside-the-Storage-Engine-Anatomy-of-a-page.aspx
但是我們可以查到如下信息:

m_type=17的這個數據類型ML map page,是在“大容量日志”模式下,記錄自上次備份以來哪些區(qū)被更改過,該頁第一個位置總是在每個文件的第7頁上,我們折回上面第一個查詢時的第三行,即PageType是ML_MAP_PAGE的那行,
并將其帶入如下SQL查詢出pageID的記錄:

發(fā)現這才是傳說中的那個第一頁總是出現在每個文件第7頁!
我們將PageID7帶入DBCC PAGE:

Oh,SHIT!這個的m_type是17!
好吧,我只能說,是我曲解了人家字面的意思,原來:
BCM ,大容量更改映射(Bulk Change Map),在數據庫緩存中對應的PageType竟然是ML_MAP_PAGE!Minimally-Logged Page!
而那個該死的BULK_OPERATION_PAGE(m_type=20)是什么東西,誰能告訴我?
另外那個UNLINKED_REORG_PAGE,應該就是排序頁吧?
相關文章
sql server實現在多個數據庫間快速查詢某個表信息的方法
這篇文章主要介紹了sql server實現在多個數據庫間快速查詢某個表信息的方法,結合實例形式分析了SQL Server多個數據庫查詢的相關操作技巧,代碼備有詳盡的注釋,需要的朋友可以參考下2017-03-03
SQL Server Bulk Insert 只需要部分字段時的方法
上午在找Bulk Insert的資料看,還轉了一篇。不巧今天下午就用上了,我遇到的需求是導出表A中的N個字段,然后導入到表B的N個字段當中。2011-10-10
sql中的 where 、group by 和 having 用法解析
這篇文章主要介紹了sql中的 where 、group by 和 having 用法解析,需要的朋友可以參考下2017-04-04

