一：背景 1. 講故事 在 SQLSERVER 的眾多阻塞場景中，有不小的一部分是由於 PFS 頁上的 閂鎖 等待造成的，畢竟寫頁操作一定是要串列化的，在面對 閂鎖(PAGELATCH_X) 等待問題上，一定要搞明白 PFS 頁到底是什麼？ 這篇就來好好聊一聊。 二：PFS 詳解 1. 什麼是 PF ...
一：背景
1. 講故事
在 SQLSERVER 的眾多阻塞場景中，有不小的一部分是由於 PFS 頁上的 閂鎖 等待造成的，畢竟寫頁操作一定是要串列化的，在面對 閂鎖(PAGELATCH_X) 等待問題上，一定要搞明白 PFS 頁到底是什麼？ 這篇就來好好聊一聊。
二：PFS 詳解
1. 什麼是 PFS 頁
我們知道資料庫是由海量的 數據頁 組成，表記錄會寫入到 數據頁 上，那海量的數據頁如何管理呢？ SQLSERVER 想到了一個辦法，從海量的數據頁中按一定規則擇取一些作為 管理頁 使用，比如：
- GAM 跟蹤區分配情況
- SGAM 跟蹤共用區分配情況
- PFS 跟蹤數據頁的空間使用情況
這裡我簡述一下吧，GAM數據頁中一個 bit 跟蹤一個 64k 的空間(一個區)，所以一個 8k 的GAM頁 可以跟蹤大約 (8 * 8192) * 64k = 4G 的空間，而 PFS 數據頁用一個 byte 跟蹤一個 8k 的數據頁，理論上可以管理 8192 * 8k = 64M 的數據。
接下來的問題是這 1byte 是如何標記一個數據頁的使用情況呢？ 簡單的畫個圖吧。
從圖中看，這一個跟蹤 byte 差不多都給塞滿了，有了這些基礎之後，接下來用一個案例來演示一下。
2. 案例演示
創建一個 MyTestDB 資料庫，新建一個 post 表，參考sql如下：
CREATE DATABASE MyTestDB
GO
USE MyTestDB
GO
CREATE TABLE post (id INT IDENTITY, content CHAR(1000))
創建好之後來觀察下 MyTestDB 的 mdf 文件中的 PFS 數據頁，可以使用 DBCC PAGE 命令，但這個命令需要獲取 fileid, pageid 這兩個參數，那如何提取呢？
- 如何提取 fileid
可以查詢 sys.database_files 系統表提取。
SELECT file_id,name,physical_name FROM sys.database_files;
- 如何提取 pageid
剛纔說過了，這種管理頁都是有規律的，比如 PFS 頁是 64M 一個，在 file_id=1 的文件中，第一個區的第1號數據頁就是 PFS 頁，即 MyTestDB.mdf 文件偏移 8192byte 的位置，這裡稍微補充一下，mdf 文件的第一個區中的 8 個 page 都是有特殊用途的，畫個簡圖如下：
接下來觀察下這個 PFS 數據頁，它的 type=11，後續我們還會對它不斷的觀察。
DBCC TRACEON(3604)
DBCC PAGE(MyTestDB,1,1,3)
------ output -----
Page @0x000001DB52882000
m_pageId = (1:1) m_headerVersion = 1 m_type = 11
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x0
m_objId (AllocUnitId.idObj) = 99 m_indexId (AllocUnitId.idInd) = 0 Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0 Metadata: IndexId = 0 Metadata: ObjectId = 99
m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 0
m_slotCnt = 1 m_freeCnt = 2 m_freeData = 8188
m_reservedCnt = 0 m_lsn = (37:192:1) m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 651443756
DB Frag ID = 1
好了，繼續測試吧，插入一條數據，觀察 PFS 頁對應的位數是否有變化？ 比如空間使用率，參考sql如下：
INSERT INTO post(content) VALUES ('aaaaa')
DBCC TRACEON(3604)
DBCC IND(MyTestDB,post,-1)
從圖中可以看到，插入的 aaaaa 記錄寫到了 240 號數據頁，跟蹤這個數據頁的byte 理論上是在 PFS 頁偏移 0n240 byte 的位置，那具體是哪一個位置的 byte 跟蹤的呢？我們用 windbg 觀察下 PFS 數據頁的記憶體頁地址即可，首先用 DBCC PAGE(MyTestDB,1,1,2) 找到 Page 頁在記憶體的首地址。
Memory Dump @0x000000C8177F8000
000000C8177F8000: 010b0000 00000000 00000000 00000000 00000000 ....................
000000C8177F8014: 00000100 63000000 0200fc1f 01000000 01000000 ....c...............
000000C8177F8028: 25000000 e0000000 1c000000 00000000 00000000 %...................
000000C8177F803C: 2c3ed426 01000000 00000000 00000000 00000000 ,>.&................
000000C8177F8050: 00000000 00000000 00000000 00000000 00009c1f ....................
000000C8177F8064: 44444444 00004444 60647060 74706070 60607060 DDDD..DD`dp`tp`p``p`
000000C8177F8078: 60707060 40404040 40404040 61706070 60606070 `pp`@@@@@@@@ap`p```p
000000C8177F808C: 60646060 60706060 60706060 60606070 40404040 `d```p```p`````p@@@@
接下來用 WinDbg 附加 SqlServer，由於前 96byte 是數據頁頭，所以理論位置應該是 000000C8177F8000+0x60 + 0n240 的位置，截圖如下：
哈哈，終於給找到了，那 0x41 是什麼意思呢？可以用 windbg 的 .formats 命令觀察一下。
0:118> .formats 41
Evaluate expression:
Hex: 00000000`00000041
Decimal: 65
Decimal (unsigned) : 65
Octal: 0000000000000000000101
Binary: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000001
對應 byte 中位解讀，可以知道當前 240 號數據頁的空間使用率為 1 ~50%，同時 數據頁已被分配。
這裡我們順帶觀察下 PageID=80 號這個 IAM 頁，看看 PFS 中如何表示它的，在記憶體中計算位置應該是 000000C8177F8000+0x60 + 0n80，輸出如下：
0:118> dp 000000C8177F8000+0x60 + 0n80 L2
000000c8`177f80b0 70607070`60606070 60302070`60606070
0:118> .formats 70
Evaluate expression:
Hex: 00000000`00000070
Decimal: 112
Decimal (unsigned) : 112
Octal: 0000000000000000000160
Binary: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01110000
再對應 byte 位解讀，可以知道當前的 80號數據頁 的四點信息：
- 當前數據頁已分配
- 當前數據頁在混合區
- 當前數據頁為 IAM 頁
- 當前為特殊管理頁
接下來再插入 4條 數據，觀察下 空間使用率 是否有變化 ?
INSERT INTO post(content) VALUES ('bbbbb')
INSERT INTO post(content) VALUES ('ccccc')
INSERT INTO post(content) VALUES ('ddddd')
INSERT INTO post(content) VALUES ('eeeee')
用 DBCC PAGE 觀察記憶體頁首地址之後，再次用 WinDBG 附加觀察，輸出如下：
0:126> .formats 42
Evaluate expression:
Hex: 00000000`00000042
Decimal: 66
Decimal (unsigned) : 66
Octal: 0000000000000000000102
Binary: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000010
從輸出可以看到已經由原來的 41 變成了 42，其中的 010 剛好表示當前數據頁為 51~80% 滿，作為校驗的話，可以直接觀察 240號 頁頭上的 PFS (1:1) = 0x42 ALLOCATED 80_PCT_FULL 描述。
DBCC TRACEON(3604)
DBCC IND(MyTestDB,post,-1)
DBCC PAGE(MyTestDB,1,240,2)
----- output -----
PAGE: (1:240)
...
PAGE HEADER:
Page @0x000001DB58F92000
...
Allocation Status
GAM (1:2) = ALLOCATED SGAM (1:3) = NOT ALLOCATED PFS (1:1) = 0x42 ALLOCATED 80_PCT_FULL
DIFF (1:6) = CHANGED ML (1:7) = NOT MIN_LOGGED
...
三：總結
總的來說 PFS頁 瓶頸主要來自於用戶創建的 臨時表 和 表變數，常常在高併發的場景下由於高頻的創建和刪除臨時表以及對臨時表的插入，SQLSERVER 不得不高頻的修改 PFS頁 造成這一塊的瓶頸，如果大家在阻塞中看到大量的PageLatch_x 等待資源，記得一定要將 Tempdb 中的 ndf 劃分為多個來分攤寫入壓力。
