頁面和範圍架構指南

適用于:SQL ServerAzure SQL資料庫Azure SQL 受控執行個體Azure SynapseAnalytics AnalyticsPlatform System (PDW)

頁面是SQL Server中資料儲存體的基本單位。 範圍是八個實際連續頁面的集合。 範圍可以協助系統有效地管理頁面。 本指南說明所有 SQL Server 版本中用於管理分頁與範圍的資料結構。 了解頁面與範圍的架構對於設計和開發有效執行的資料庫很重要。

頁面和範圍

SQL Server 中資料儲存的基本單位是分頁。 配置給資料庫中資料檔案 (.mdf 或 .ndf) 的磁碟空間會以邏輯方式分割成連續從 0 到 n的分頁。 磁碟 I/O 作業在分頁層次上操作。 也就是說,SQL Server 會讀取或寫入整個資料分頁。

範圍是八個實體連續分頁的集合,用來有效地管理這些分頁。 所有頁面都會組織成範圍。

頁面

在一般書籍中,所有內容都會在頁面上撰寫。 類似于書籍,SQL Server會在頁面上寫入所有資料列,而所有資料頁的大小相同:8 KB。 在書籍中,大部分的頁面都包含資料 - 書籍的主要內容,而某些頁面包含內容的相關中繼資料 (例如目錄和索引) 。 同樣地,SQL Server並無不同:大部分頁面都包含使用者所儲存的實際資料列;這些資料列稱為資料頁文字/影像頁面, (特殊案例) 。 索引頁包含有關資料所在位置的索引參考。 最後,有一些 系統頁面 會儲存有關資料組織的各種中繼資料。

每個分頁的開頭為 96 個位元組的標頭,用來儲存與分頁有關的系統資訊。 此資訊包括頁碼、分頁類型、分頁上可用空間的數量,以及擁有分頁的物件配置單位識別碼。

下表顯示 SQL Server 資料庫資料檔案中使用的分頁類型。

分頁類型 內容
資料 當資料列中的文字設定為 ON 時,具有所有資料的資料列, 除了 textNtextimageNvarchar (max) Varchar (max) Varbinary (max) xml 資料。
索引 索引項目
文字/影像 大型物件資料類型: textNtextimageNvarchar (max) Varchar (max ) 、 Varbinary (max) xml 資料。

當資料列超過 8 KB 時,可變長度資料行: VarcharNvarcharVarbinarySQL_variant
整體配置對應 (GAM)

共用的整體配置對應 (SGAM)
有關是否配置範圍的資訊。
分頁可用空間 (PFS) 有關分頁配置和分頁中可用空間的資訊。
IAM) (索引配置對應 有關每個配置單位資料表或索引所用範圍的資訊。
大量複製變更對應 (BCM) 有關每個配置單位從上一次 BACKUP LOG 陳述式後被大量作業修改之範圍的資訊。
差異式變更對應 (DCM) 有關每個配置單位追蹤自從上個 BACKUP DATABASE 陳述式之後發生變更的範圍的資訊。

注意

記錄檔不包含頁面。 它們包含一系列沒有固定大小的記錄檔記錄。

資料列會以序列方式儲存在頁面上,從標頭之後立即開始。 資料列位移資料表從頁面結尾開始,而且每個資料表分別為分頁上每一列包含一個項目。 每個資料列位移專案都會儲存資料列第一個位元組與頁面開頭的距離。 因此,資料列位移資料表的功能是協助SQL Server快速找出頁面上的資料列。 資料列位移資料表的項目順序與分頁中的資料列順序是相反的。

SQL Server資料頁面的圖表。

大型資料列支援

資料列無法跨越頁面;不過,資料列的部分可能會從資料列的頁面移出,因此資料列可能非常大。 頁面上單一資料列內含的資料和額外負荷上限為 8,060 個位元組。 這不包括儲存在文字/影像頁面類型中的資料。

對於包含 VarcharNvarcharVarbinarySQL_variant 資料行 的資料表而言,這項限制會寬鬆。 當資料表中所有固定和變數資料行的總數據列大小超過 8,060 位元組的限制時,SQL Server動態地將一個或多個可變長度資料行移至ROW_OVERFLOW_DATA配置單位中的頁面,從最大寬度的資料行開始。

只要插入或更新作業使得資料列的總大小超過 8,060 個位元組的限制時,就會執行這個動作。 當資料行移至 ROW_OVERFLOW_DATA 配置單位中的分頁時,會保留 IN_ROW_DATA 配置單位中原始頁面上的 24 個位元組指標。 若是後續作業縮小了資料列大小,SQL Server 則會動態地將資料行移回原始資料頁。

資料列溢位考慮

資料列不能位於多個頁面上,而且如果可變長度資料類型欄位的組合大小超過 8060 位元組的限制,則可能會溢位。 為了說明,資料表可以建立兩個數據行:一個 Varchar (7000) ,另一個 Varchar (2000) 。 個別的資料行都不能超過 8060 個位元組,但如果填滿每個資料行的整個寬度,則合併它們可能會這麼做。 SQL Server可能會動態地將Varchar (7000) 可變長度資料行移至ROW_OVERFLOW_DATA配置單位中的頁面。 當您結合 VarcharNvarcharVarbinarySQL_variant或 CLR 使用者定義類型資料行超過每個資料列 8,060 個位元組時,請考慮下列事項:

  • 當記錄因更新作業而加長時,這些大型記錄會動態地移到另一個分頁上。 當更新作業將記錄縮短時,則會造成這些記錄移回 IN_ROW_DATA 配置單位中的原始分頁。

    查詢與執行其他選取作業 (例如在包含資料列溢位資料的大型記錄上執行排序或聯結) 時,處理速度將會變慢,這是因為這些記錄會以同步而不是非同步的方式來處理。

    因此,當您設計具有多個 VarcharNvarcharVarbinarySQL_variant或 CLR 使用者定義類型資料行的資料表時,請考慮可能流過的資料列百分比,以及可能會查詢此溢位資料的頻率。 如果可能會經常在許多資料列溢位資料的資料列上執行查詢,請考慮將資料表正規化,以便將一些資料行移到另一個資料表。 然後便可以用非同步 JOIN 作業進行查詢。

  • 個別資料行的長度仍然必須落在 VarcharNvarcharVarbinarySQL_variant和 CLR 使用者定義類型資料行的 8,000 個位元組的限制內。 只有它們合起來的長度才可以超過資料表的每個資料列 8,060 個位元組的限制。

  • 其他資料類型資料行的總和,包括 charNchar 資料,必須落在 8,060 位元組的資料列限制內。 大型物件資料也可免除 8,060 個位元組的資料列限制。

  • 叢集索引的索引鍵不能包含具有ROW_OVERFLOW_DATA配置單位中現有資料的 Varchar 資料行。 如果在 varchar 資料行上建立叢集索引,且現有的資料在 IN_ROW_DATA 配置單位中,則後續在可能發送資料非資料列的資料行上進行的插入或更新動作會失敗。 如需配置單位的詳細資訊,請參閱 索引架構和設計指南

  • 您可以納入包含資料列溢位資料的資料行,做為非叢集索引的索引鍵或非索引鍵資料行。

  • 使用疏鬆資料行之資料表的記錄大小限制為 8,018 個位元組。 當轉換的資料加上現有記錄資料超過 8,018 個位元組時,就會傳回 MSSQLSERVER ERROR 576。 當資料行在疏鬆和非剖析類型之間轉換時,Database Engine 會保留目前記錄資料的複本。 這樣做會暫時將記錄所需的儲存體加倍。

  • 若要取得可能包含資料列溢位資料之資料表或索引的相關資訊,請使用 sys.dm_db_index_physical_stats 動態管理函式。

Extents

範圍即管理空間中的基本單位。 一個範圍是 8 個連續實體分頁,也就是 64 KB。 這表示SQL Server資料庫每 MB 有 16 個範圍。

SQL Server 有兩種範圍類型︰

  • 制式的範圍將由一個物件所擁有;範圍中的所有八個頁面只能被擁有的物件所使用。
  • 混合的範圍最多可被八個物件所共用。 範圍中的 8 個分頁都可以由不同的物件所擁有。

顯示統一和混合範圍的圖表。

SQL Server 2014 (12.x) ,Database Engine 不會將整個範圍配置給具有少量資料的資料表。 新的資料表或索引,一般會從混合的範圍中配置分頁。 當資料表或索引成長至擁有八個分頁之後,接著會為後續配置切換成使用制式的範圍。 如果現有資料表有足夠的資料列可在索引中產生八個分頁,若對該資料表建立索引,索引的所有配置都將採用制式的範圍。

從 2016 SQL Server 2016 (13.x) 開始,使用者資料庫中大部分配置的預設,而且 tempdb 是使用統一範圍,但屬於IAM 鏈結前八頁的配置除外。 mastermsdbmodel 資料庫的配置仍會保留先前的行為。

注意

在SQL Server中,最多包含 SQL Server 2014 (12.x) ,您可以使用追蹤旗標 (TF) 1118 變更預設配置,以一律使用統一範圍。 如需此追蹤旗標的詳細資訊,請參閱 DBCC TRACEON - 追蹤旗標

從 2016 SQL Server 2016 (13.x) 開始,TF 1118 所提供的功能會自動針對 tempdb 和所有使用者資料庫啟用。 對於使用者資料庫,此行為是由 SET MIXED_PAGE_ALLOCATION 的選項 ALTER DATABASE 所控制,預設值設定為 OFF,而 TF 1118 沒有作用。 如需詳細資訊,請參閱 ALTER DATABASE SET 選項 (Transact-SQL)

從 SQL Server 2012 (11.x) 開始, sys.dm_db_database_page_allocations 系統函式可以報告資料庫、資料表、索引和資料分割的頁面配置資訊。

重要

sys.dm_db_database_page_allocations 系統函數並未記載,而且可能會變更。 我們無法確保其相容性。

從 2019 SQL Server 2019 (15.x) 開始,sys.dm_db_page_info系統函式可供使用,並傳回資料庫中頁面的相關資訊。 函式會傳回一個資料列,其中包含頁面的標頭資訊,包括 object_idindex_idpartition_id 。 在大部分情況下,有此函式就不需要使用 DBCC PAGE

管理範圍配置和可用空間

管理範圍配置與追蹤可用空間的 SQL Server 資料結構相當簡單。 具有下列好處:

  • 可用空間的資訊是緊密壓縮的,因此只有少數的分頁包含此資訊。

    這會增加速度,方法是減少擷取配置資訊所需的磁片讀取數目。 此外,還可以增加配置頁保存於記憶體中的機會,而不需額外的讀取。

  • 大部分的配置資訊不會鏈結在一起。 這可以簡化配置資訊的維護工作。

    每個分頁配置或取消配置都可迅速執行。 這可減少配置或釋出分頁所需之並行工作間的競爭。

管理範圍配置

SQL Server 使用兩種配置對應來記錄範圍的配置:

  • 整體配置對應 (GAM)

    GAM 分頁可記錄已配置哪些範圍。 每個 GAM 可涵蓋 64,000 個範圍,或接近 4 GB 的資料。 GAM 在涵蓋的間隔內,每個範圍都有 1 位。 如果位為 1 ,則範圍是免費的;如果位為 0 ,則會配置範圍。

  • 共用的整體配置對應 (SGAM)

    SGAM 分頁可記錄哪些範圍目前當作混合範圍使用,並至少擁有一個未使用的分頁。 每個 SGAM 可涵蓋 64,000 個範圍,或接近 4 GB 的資料。 SGAM 在涵蓋的間隔中,每個範圍都有 1 位。 如果位為 1 ,則範圍會當做混合範圍使用,且具有免費頁面。 如果位是 0 ,則範圍不會當做混合範圍使用,或者它是混合範圍,而且正在使用其所有頁面。

每個範圍都將根據其目前的用法,在 GAM 與 SGAM 中擁有下列的位元模式設定。

範圍的目前用法 GAM 位元設定 SGAM 位元設定
可用,且未使用 1 0
制式範圍,或完全混合範圍 0 0
具有可用分頁的混合範圍 0 1

如此可產生簡單的範圍管理演算法。

  • 為了配置統一的範圍,Database Engine 會搜尋 GAM 以取得一個 1 位,並將其設定為 0
  • 若要尋找具有可用頁面的混合範圍,Database Engine 會搜尋 SGAM 一點 1
  • 若要配置混合範圍,Database Engine 會搜尋 GAM 中的一個 1 位,並將它 0 設定為 ,然後將 SGAM 中的對應位設定為 1
  • 若要解除配置範圍,Database Engine 可確保 GAM 位已設定為 1 ,而 SGAM 位已設定為 0

Database Engine 在內部使用的演算法比本文所述更複雜,因為 Database Engine 會將資料平均散發在資料庫中。 即使如此,因為實際的演算法不需有管理範圍配置資訊的鏈結,所以可加以簡化。

追蹤可用空間

頁面可用空間 (PFS) 頁面會記錄每個頁面的配置狀態、個別頁面是否已配置,以及每個頁面的可用空間量。 每個頁面的 PFS 都有 1 個位元組,記錄頁面是否已配置,如果是空白,則為空白、1 到 50% 已滿、51 到 80% 已滿、81 到 95% 已滿,或 96 到 100%。

當範圍配置給物件之後,Database Engine 會使用 PFS 分頁,來記錄範圍中哪些分頁是已配置或可用的。 當 Database Engine 必須配置新分頁時,就會使用此資訊。 頁面中的可用空間量只會針對堆積和文字/影像頁面進行維護。 當 Database Engine 必須尋找具有可用空間的分頁來存放新插入的資料列時,就會用到它。 索引不需要追蹤頁面可用空間,因為插入新資料列的點是由索引鍵值所設定。

它會針對追蹤的每個額外範圍,在資料檔案中新增 PFS、GAM 或 SGAM 分頁。 在第一個 PFS 分頁之後 8,088 個分頁,有新的 PFS 分頁,而後續的其他 PFS 分頁以 8,088 個分頁為間隔。 為了說明,分頁識別碼 1 是 PFS 分頁,分頁識別碼 8088 是 PFS 分頁,分頁識別碼 16176 是 PFS 分頁,以此類推。

在第一個 GAM 分頁之後 64,000 個範圍,有新的 GAM 分頁,它會追蹤其後的 64,000 個範圍;順序會以 64,000 個範圍為間隔繼續。 同樣地,在第一個 SGAM 分頁之後 64,000 個範圍,有新的 SGAM 分頁,而後續的其他 SGAM 分頁以 64,000 個範圍為間隔。

下圖顯示 Database Engine 用來配置及管理範圍的分頁順序。

此圖顯示用於管理範圍的頁面順序。

管理物件所使用的空間

[索引配置對應 (IAM)] 頁面會對應配置單位所使用資料庫檔案 4 GB 部分中的範圍。 配置單位為下列三種類型中的一種:

  • IN_ROW_DATA

    保存堆積或索引的資料分割。

  • LOB_DATA

    保留大型物件 (LOB) 資料類型,例如 xmlVarbinary (max) Varchar (max)

  • ROW_OVERFLOW_DATA

    保留 儲存在 VarcharNvarcharVarbinarySQL_variant 超過 8,060 位元組資料列大小限制的可變長度資料。

堆積或索引的每個資料分割都會至少包含一個 IN_ROW_DATA 配置單位。 視堆積或索引結構描述而定,資料分割也可能會包含 LOB_DATA 或 ROW_OVERFLOW_DATA 配置單位。

IAM 頁面涵蓋檔案中的 4 GB 範圍,和 GAM 和 SGAM 頁面的涵蓋範圍相同。 如果配置單位包含一個以上檔案的範圍,或超過一個 4 GB 範圍的檔案,IAM 鏈結中就會連結多個 IAM 頁面。 因此,每個配置單位在它擁有範圍的每個檔案上都會至少擁有一個 IAM。 如果配置給配置單位的檔案範圍超過一個 IAM 頁面所能記錄的範圍,該檔案也會有不止一個 IAM。

顯示 IAM 頁面分佈的圖表。

IAM 頁面是視需要配置給每個配置單位,而且在檔案中的位置是隨機的。 sys.system_internals_allocation_units 系統檢視指向配置單位的第一個 IAM 分頁。 該配置單位的所有 IAM 分頁都會連結成一條 IAM 鏈結。

重要

sys.system_internals_allocation_units 系統檢視僅用於內部,且往後可能會變更。 我們無法確保其相容性。 在 Azure SQL Database 中無法取得此檢視。

此圖顯示每個配置單位鏈結中連結的 IAM 頁面。

IAM 頁面擁有一個標頭,指出 IAM 頁面所對應範圍之範疇中的開始範圍。 IAM 頁面也擁有一個大型點陣圖,它裡面的每個位元都代表一個範圍。 對應中的第一個位元代表了範疇中的第一個範圍,第二個位元代表了第二個範圍,其餘依此類推。 如果位是 0 ,則表示的範圍不會配置給擁有 IAM 的配置單位。 如果位為 1 ,則表示的範圍會配置給擁有 IAM 頁面的配置單位。

當 Database Engine 必須插入新的資料列,且目前頁面中沒有可用空間時,它會使用 IAM 和 PFS 頁面來尋找要配置的頁面,或是針對堆積或文字/影像頁面,具有足夠空間來保存資料列的頁面。 Database Engine 將使用 IAM 頁面來尋找配置給該配置單位的範圍。 對於每個範圍而言,Database Engine 會搜尋 PFS 頁面,查看是否有可用的頁面。 每個 IAM 和 PFS 頁面涵蓋許多資料頁,因此資料庫中有幾個 IAM 和 PFS 頁面。 這代表 IAM 與 PFS 頁面通常位於 SQL Server 緩衝集區的記憶體中,因此可以快速地被搜尋到。 對於索引而言,新資料列的插入點是由索引鍵設定;但需要新頁面時,就會發生上述程序。

只有在資料庫引擎無法快速在現有範圍內找到具有足夠空間來保存插入之資料列的頁面時,資料庫引擎才會將新的範圍配置給配置單位。

比例填滿配置

Database Engine 會使用 比例填滿配置 演算法,從檔案群組中可用的範圍配置範圍。 在具有兩個檔案的相同檔案群組中,如果一個檔案具有另一個檔案的兩倍可用空間,則會從檔案中配置兩個頁面,並針對從另一個檔案配置的每個頁面提供可用空間。 這代表檔案群組中的每個檔案都擁有類似的空間使用百分比。

追蹤修改的範圍

SQL Server使用兩個內部資料結構來追蹤大量複製作業修改的範圍,以及上次完整備份後修改的範圍。 這些資料結構大幅加速差異備份; 同時也在資料庫使用大量記錄復原模式時,提高了大量複製作業記錄的速度。 如同 GAM 和 SGAM 頁面,這些結構是點陣圖,其中每個位都代表單一範圍。

  • 差異式變更對應 (DCM)

    這種對應會追蹤自從上個 BACKUP DATABASE 陳述式之後發生變更的範圍。 如果範圍的位為 1 ,則範圍自上 BACKUP DATABASE 一個語句之後已修改。 如果位為 0 ,則範圍尚未修改。

    差異備份只讀取 DCM 分頁,找出哪些範圍經過修改。 這可大幅減少差異式備份必須掃描的分頁數目。 差異備份執行的時間長度與自上次 BACKUP DATABASE 語句以來修改的範圍數目成正比,而不是資料庫的整體大小。

  • 大量複製變更對應 (BCM)

    這會追蹤自上 BACKUP LOG 一個語句以來,大容量日誌作業已修改的範圍。 如果某個範圍的位是 1 ,則範圍已由最後 BACKUP LOG 一個語句之後的大容量日誌作業修改。 如果位是 0 ,則大量記錄作業尚未修改範圍。

    雖然 BCM 分頁出現在所有資料庫中,但它們只適用於資料庫正在使用大量複製復原模式時。 在此復原模式中,當執行 BACKUP LOG 時,備份處理序會掃描 BCM 來找出修改過的範圍。 接著將這些範圍記錄到記錄備份中。 如果資料庫從資料庫備份和交易記錄備份序列還原,這會復原大容量日誌作業。 BCM 頁面與使用簡單復原模式的資料庫無關,因為不會記錄任何大容量日誌作業。 它們與使用完整復原模式的資料庫無關,因為該復原模式會將大容量日誌作業視為完整記錄作業。

DCM 分頁與 BCM 分頁之間的間隔與 GAM 和 SGAM 分頁的間隔一樣,亦即 64,000 個範圍。 DCM 和 BCM 頁面位於實體檔案中的 GAM 和 SGAM 頁面後方,如下所示:

此圖顯示特殊頁面的間隔分佈。

另請參閱