聊一聊 SQLSERVER 的行不能跨頁

一線碼農發表於2022-12-31
SQLServer

一：背景

1. 講故事

相信有很多朋友在學習 SQLSERVER 的時候都聽說過這句話，但大多都是記憶為主，最近在研究 SQLSERVER，所以我們從 底層儲存 的角度來深入理解下。

二：理解資料頁

1. 資料頁的組織

在前面的文章中我也說過，一個 資料頁 是 8k 大小，那這 8k 是如何組織的呢？ 為了更好的表述，我先來畫一張圖，大概像下面這樣。

從圖中可以看到，一個資料頁大概分為三部分：

  • 頁頭

這一塊相當於 資料頁 的後設資料區，標記著這個資料頁型別和各種統計資訊。

  • 資料儲存區

這裡存放的就是表的每條記錄以及記錄的相關後設資料，這個後設資料統計著諸如定長，變長欄位個數，記錄型別 等等。

  • 記錄槽位列表

slot 槽位記錄了 行記錄 在這個資料頁上的偏移地址，過一會我們驗證下即可，如果用 C++ 虛擬碼，大概是這樣。


//行記錄
struct _record
{
	char meta_s[8];
	int field1;
	char field2;
	short fieldn;
	char meta_e[8];
};

class page
{
private:
	char header[96];	 //1.頁頭

	_record records[n];	 //2. 行記錄

	short slots[n];		 //3. 槽位 （指標由後向前）
};

2. 理解行的最大大小

相信大家從各種教科書中都能知道，我們能定義的最大行大小是 8060 byte，這包括行的 7byte 後設資料大小，所以我們人肉能定義的大小隻能是 8053byte，根據上一節的理解，這 8060byte 是落在 資料儲存區 的，這裡我們簡單算一下頁面是否剛好佔滿或者是否有保留區？接下來用一個公式簡單算一下。


0:103> ? 0n8192 - 0n96 -0n2 - 0n8060
Evaluate expression: 34 = 00000000`00000022

上面的公式為： 保留大小 = 頁面大小 - 頁面頭 - slot槽位 - 資料儲存區，這麼一算頁面中還真有 34byte 的保留大小。

接下來我們簡單驗證下這個推理，首先自定義一行 8054byte 的大小看是否能透過？


USE MyTestDB
GO
CREATE TABLE t6 (a char(8000), b CHAR(54))
INSERT INTO t6 VALUES(REPLICATE('a',8000), REPLICATE('b',53))

從錯誤資訊中可以清楚的看到，我的行記錄總大小是 8061, 超過了系統規定的行記錄大小8060。

接下來我們驗證下 資料頁 最小的保留大小是不是 34byte ？ 找到表資料頁即可。


USE MyTestDB
GO
CREATE TABLE t6 (a char(8000), b CHAR(53))
INSERT INTO t6 VALUES(REPLICATE('a',8000), REPLICATE('b',53))

SELECT * FROM dbo.t6;

DBCC TRACEON(3604)
DBCC IND(MyTestDB,t6,-1)

從圖中可以看到行記錄是分配在 456 號 資料頁上，接下來用 DBCC PAGE 觀察一下。


DBCC PAGE(MyTestDB,1,456,2)

輸出如下：

SQL Server 分析和編譯時間: 
   CPU 時間 = 0 毫秒，佔用時間 = 0 毫秒。

PAGE: (1:456)


BUFFER:


BUF @0x00000251CEB3F180

bpage = 0x00000251BCBE2000          bPmmpage = 0x0000000000000000       bsort_r_nextbP = 0x00000251CEB3F0D0
bsort_r_prevbP = 0x0000000000000000 bhash = 0x0000000000000000          bpageno = (1:456)
bpart = 0                           ckptGen = 0x0000000000000000        bDirtyRefCount = 0
bstat = 0x9                         breferences = 0                     berrcode = 0
bUse1 = 38957                       bstat2 = 0x0                        blog = 0x15ab215a
bsampleCount = 0                    bIoCount = 0                        resPoolId = 0
bcputicks = 0                       bReadMicroSec = 135                 bDirtyContext = 0x0000000000000000
bDbPageBroker = 0x0000000000000000  bdbid = 10                          bpru = 0x00000251CA5A0040

PAGE HEADER:


Page @0x00000251BCBE2000

m_pageId = (1:456)                  m_headerVersion = 1                 m_type = 1
m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0x8200
m_objId (AllocUnitId.idObj) = 193   m_indexId (AllocUnitId.idInd) = 256 
Metadata: AllocUnitId = 72057594050576384                                
Metadata: PartitionId = 72057594043826176                                Metadata: IndexId = 0
Metadata: ObjectId = 1349579846     m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 8057                      m_slotCnt = 1                       m_freeCnt = 34
m_freeData = 8156                   m_reservedCnt = 0                   m_lsn = (37:1704:26)
m_xactReserved = 0                  m_xdesId = (0:0)                    m_ghostRecCnt = 0
m_tornBits = 1904590527             DB Frag ID = 1                      

Allocation Status

GAM (1:2) = ALLOCATED               SGAM (1:3) = NOT ALLOCATED          PFS (1:1) = 0x44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED                ML (1:7) = NOT MIN_LOGGED           

DATA:


Memory Dump @0x000000E456778000

000000E456778000:   01010000 00820001 00000000 0000791f 00000000  ..............y.....
000000E456778014:   00000100 c1000000 2200dc1f c8010000 01000000  ........"...........
000000E456778028:   25000000 a8060000 1a000000 00000000 00000000  %...................
000000E45677803C:   bfbe8571 00000000 00000000 00000000 00000000  ...q................
000000E456778050:   00000000 00000000 00000000 00000000 1000791f  ..................y.
000000E456778064:   61616161 61616161 61616161 61616161 61616161  aaaaaaaaaaaaaaaaaaaa
...
000000E456779FCC:   62626262 62626262 62626262 62020000 00002121  bbbbbbbbbbbbb.....!!
000000E456779FE0:   21212121 21212121 21212121 21212121 21212121  !!!!!!!!!!!!!!!!!!!!
000000E456779FF4:   21212121 21212121 21216000                    !!!!!!!!!!`.

OFFSET TABLE:

Row - Offset                        
0 (0x0) - 96 (0x60)

剛才也說了，頁面後設資料佔了 96byte，裡面包含了各種統計資訊，比如 m_freeCnt = 34 就是當前頁面的剩餘空間，這個和我們剛才的計算公式是保持一致的，這 34byte 就是頁面末位預設的 0x21 填充符。

三：總結

其實從上面的分析中可以得出，資料頁還是有 34byte 的保留空間的，可能是出於某些原因不想再塞了，當然也可以用 WinDbg 觀察下原始碼邏輯，可以下一個 C++ 異常斷點。


0:113> sxe eh
0:113> g
(6aec.6a20): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
KERNELBASE!RaiseException+0x69:
00007ff8`f61b3e49 0f1f440000      nop     dword ptr [rax+rax]
0:020> k
 # Child-SP          RetAddr               Call Site
00 00000022`cddf7b80 00007ff8`dd2f6720     KERNELBASE!RaiseException+0x69
01 00000022`cddf7c60 00007ff8`bab85763     VCRUNTIME140!_CxxThrowException+0x90 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 75] 
02 00000022`cddf7cc0 00007ff8`bab85339     sqldk!TurnUnwindAndThrowImpl+0x582
03 00000022`cddf81b0 00007ff8`bab8531b     sqldk!SOS_OS::TurnUnwindAndThrow+0x9
04 00000022`cddf81e0 00007ff8`bab84fca     sqldk!ex_raise2+0x56e
05 00000022`cddf8520 00007ff8`5cf2c056     sqldk!ex_raise+0xc3
06 00000022`cddf85a0 00007ff8`5cf2e54d     sqlmin!RaiseHoBtRowsizeError+0x156
07 00000022`cddf8600 00007ff8`5c33ac06     sqlmin!SECreateRowset+0x444
08 00000022`cddfa940 00007ff8`995632f8     sqlmin!DDLAgent::SECreateRowsets+0x2e0
...

從執行緒棧可以看到，邏輯是在 SECreateRowset() 方法中丟擲了 RaiseHoBtRowsizeError() 異常，應該是一個常量 cmp 比較，留給大家研究吧。

相關文章