ページとエクステントのアーキテクチャ ガイドPages and Extents Architecture Guide

適用対象: ○SQL Server ○Azure SQL Database ○Azure SQL Data Warehouse ○Parallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database yesAzure SQL Data Warehouse yesParallel Data Warehouse

ページは、SQL ServerSQL Server のデータ ストレージの基本単位です。The page is the fundamental unit of data storage in SQL ServerSQL Server. エクステントは物理的に連続する 8 ページをまとめたものです。An extent is a collection of eight physically contiguous pages. エクステントを使用すると、ページを効率的に管理できます。Extents help efficiently manage pages. このガイドでは、すべてのバージョンの SQL Server でページとエクステントの管理に使用されるデータ構造について説明します。This guide describes the data structures that are used to manage pages and extents in all versions of SQL Server. ページとエクステントのアーキテクチャを理解することは、効率的に実行されるデータベースを設計、開発するうえで重要です。Understanding the architecture of pages and extents is important for designing and developing databases that perform efficiently.

ページとエクステントPages and Extents

SQL ServerSQL Server のデータ ストレージの基本単位はページです。The fundamental unit of data storage in SQL ServerSQL Server is the page. データベースのデータ ファイル (.mdf または .ndf) に割り当てられたディスク領域は、0 ~ n の連番が付けられたページに論理的に分割されます。The disk space allocated to a data file (.mdf or .ndf) in a database is logically divided into pages numbered contiguously from 0 to n. ディスク I/O 操作は、このページ レベルで実行されます。Disk I/O operations are performed at the page level. つまり、SQL Server では、データ ページ全体に対して読み取りや書き込みが行われます。That is, SQL Server reads or writes whole data pages.

エクステントは、物理的に連続する 8 ページをまとめたもので、ページを効率的に管理するために使用されます。Extents are a collection of eight physically contiguous pages and are used to efficiently manage the pages. すべてのページは、エクステントに格納されます。All pages are stored in extents.

ページPages

SQL ServerSQL Server では、ページのサイズは 8 KB です。In SQL ServerSQL Server, the page size is 8-KB. したがって、SQL ServerSQL Server データベースには 1 MB あたり 128 ページあります。This means SQL ServerSQL Server databases have 128 pages per megabyte. 各ページの先頭には 96 バイトのヘッダーがあり、ここには各ページに関するシステム情報が格納されています。Each page begins with a 96-byte header that is used to store system information about the page. この情報には、ページ番号、ページの種類、ページ上の空き容量、そのページを所有しているオブジェクトのアロケーション ユニット ID が含まれます。This information includes the page number, page type, the amount of free space on the page, and the allocation unit ID of the object that owns the page.

次の表に、SQL ServerSQL Server データベースのデータ ファイルで使用されるページの種類を示します。The following table shows the page types used in the data files of a SQL ServerSQL Server database.

ページの種類Page type 目次Contents
DataData text、ntext、image、nvarchar(max)、varchar(max)、varbinary(max)、xml データを除くすべてのデータが含まれるデータ行 (text in row が ON に設定されている場合)。Data rows with all data, except text, ntext, image, nvarchar(max), varchar(max), varbinary(max), and xml data, when text in row is set to ON.
インデックスIndex インデックスのエントリ。Index entries.
テキスト/イメージText/Image ラージ オブジェクト データ型: text、ntext、image、nvarchar(max)、varchar(max)、varbinary(max)、xml データLarge object data types: (text, ntext, image, nvarchar(max), varchar(max), varbinary(max), and xml data)
可変長列 (データ行のサイズが 8 KB を超える場合): varchar、nvarchar、varbinary、sql_variantVariable length columns when the data row exceeds 8 KB: (varchar, nvarchar, varbinary, and sql_variant)
グローバル アロケーション マップ、セカンダリ グローバル アロケーション マップGlobal Allocation Map, Shared Global Allocation Map エクステントが割り当てられているかどうかについての情報。Information about whether extents are allocated.
ページ空き容量 (PFS)Page Free Space (PFS) ページ割り当てとページ上で使用可能な空き容量に関する情報。Information about page allocation and free space available on pages.
Index Allocation Map (Index Allocation Map)Index Allocation Map テーブルまたはインデックスによって使用されるエクステントに関するアロケーション ユニットごとの情報。Information about extents used by a table or index per allocation unit.
一括変更マップBulk Changed Map 最後の BACKUP LOG ステートメント以降の一括操作で変更されたエクステントに関するアロケーション ユニットごとの情報。Information about extents modified by bulk operations since the last BACKUP LOG statement per allocation unit.
差分変更マップDifferential Changed Map 最後の BACKUP DATABASE ステートメント以降に変更されたエクステントに関するアロケーション ユニットごとの情報。Information about extents that have changed since the last BACKUP DATABASE statement per allocation unit.

注意

ログ ファイルにはページではなく、一連のログ レコードが含まれます。Log files do not contain pages; they contain a series of log records.

データ行はヘッダーの直後から始まり、ページ上に連続的に配置されます。Data rows are put on the page serially, starting immediately after the header. ページの末尾から行オフセット テーブルが始まります。各行オフセット テーブルにはページ上の 1 行につき 1 つのエントリが格納されます。A row offset table starts at the end of the page, and each row offset table contains one entry for each row on the page. 各エントリには、その行の最初のバイトがページの先頭からどれだけ離れているかが記録されます。Each entry records how far the first byte of the row is from the start of the page. 行オフセット テーブル内のエントリは、ページ上の行と逆の順序になっています。The entries in the row offset table are in reverse sequence from the sequence of the rows on the page.

page_architecture

大きな行のサポートLarge Row Support

行は複数のページにまたがることができません。ただし、行の一部をその行のページから移動することで、事実上大きな行を実現できます。Rows cannot span pages, however portions of the row may be moved off the row's page so that the row can actually be very large. ページの 1 行に格納できるデータおよびオーバーヘッドの量は、最大 8,060 バイト (8 KB) です。The maximum amount of data and overhead that is contained in a single row on a page is 8,060 bytes (8-KB). ただし、これには Text/Image の種類のページに格納されているデータは含まれません。However, this does not include the data stored in the Text/Image page type.

varchar 型、nvarchar 型、varbinary 型、または sql_variant 型の列を含むテーブルでは、この制限は緩和されます。This restriction is relaxed for tables that contain varchar, nvarchar, varbinary, or sql_variant columns. テーブル内のすべての固定長列と可変長列の行サイズの合計が、8,060 バイトの制限を超過した場合、SQL ServerSQL Server は、サイズの最も大きなものから順に動的に 1 つ以上の可変長列を ROW_OVERFLOW_DATA アロケーション ユニットのページに移動します。When the total row size of all fixed and variable columns in a table exceeds the 8,060-byte limitation, SQL ServerSQL Server dynamically moves one or more variable length columns to pages in the ROW_OVERFLOW_DATA allocation unit, starting with the column with the largest width.

挿入操作または更新操作により行の合計サイズが 8,060 バイトの制限を超えると、必ずこの処理が実行されます。This is done whenever an insert or update operation increases the total size of the row beyond the 8,060-byte limit. 列が ROW_OVERFLOW_DATA アロケーション ユニットのページに移動された場合、IN_ROW_DATA アロケーション ユニットに元のページの 24 バイトのポインターが保持されます。When a column is moved to a page in the ROW_OVERFLOW_DATA allocation unit, a 24-byte pointer on the original page in the IN_ROW_DATA allocation unit is maintained. その後の操作により、行サイズが削減されると、SQL ServerSQL Server は動的に列を元のデータ ページに戻します。If a subsequent operation reduces the row size, SQL ServerSQL Server dynamically moves the columns back to the original data page.

行のオーバーフローに関する注意点Row-Overflow Considerations

varchar 型、nvarchar 型、varbinary 型、sql_variant 型、または CLR ユーザー定義型の列の組み合わせが 1 行あたり 8,060 バイトを超える場合は、次のことを考慮してください。When you combine varchar, nvarchar, varbinary, sql_variant, or CLR user-defined type columns that exceed 8,060 bytes per row, consider the following:

  • 更新操作に基づいてレコードが大きくなると、大きなレコードが別のページに動的に移動されます。Moving large records to another page occurs dynamically as records are lengthened based on update operations. レコードが短くなる更新操作が発生すると、レコードが IN_ROW_DATA アロケーション ユニット内の元のページに移動することがあります。Update operations that shorten records may cause records to be moved back to the original page in the IN_ROW_DATA allocation unit. 行オーバーフロー データを含む大きなレコードで、クエリを実行したり並べ替えや結合などの他の選択操作を実行すると、処理に時間がかかります。これは、これらのレコードが非同期にではなく同期的に処理されるためです。Querying and performing other select operations, such as sorts or joins on large records that contain row-overflow data slows processing time, because these records are processed synchronously instead of asynchronously.
    したがって、複数の varchar 型、nvarchar 型、varbinary 型、sql_variant 型、または CLR ユーザー定義型の列を含むテーブルをデザインするときは、オーバーフローする可能性が高い行の割合と、このオーバーフロー データへのクエリが実行される頻度を考慮します。Therefore, when you design a table with multiple varchar, nvarchar, varbinary, sql_variant, or CLR user-defined type columns, consider the percentage of rows that are likely to flow over and the frequency with which this overflow data is likely to be queried. 行オーバーフロー データの多くの行にクエリが頻繁に実行される可能性が高い場合は、いくつかの列を別のテーブルに移動して、テーブルのサイズを正規化することを検討します。If there are likely to be frequent queries on many rows of row-overflow data, consider normalizing the table so that some columns are moved to another table. これにより、非同期結合操作でクエリを行えるようになります。This can then be queried in an asynchronous JOIN operation.
  • varchar 型、nvarchar 型、varbinary 型、sql_variant 型、および CLR ユーザー定義型の個々の列の長さは、8,000 バイトの制限の範囲内に収まる必要があります。The length of individual columns must still fall within the limit of 8,000 bytes for varchar, nvarchar, varbinary, sql_variant, and CLR user-defined type columns. 8,060 バイトというテーブル行の制限を超えることができるのは、これらの列を組み合わせた長さだけです。Only their combined lengths can exceed the 8,060-byte row limit of a table.
  • char 型や nchar 型のデータなど、他のデータ型の列の合計は、8,060 バイトの行の制限の範囲内に収まる必要があります。The sum of other data type columns, including char and nchar data, must fall within the 8,060-byte row limit. ラージ オブジェクト データにも、8,060 バイトの行の制限は適用されません。Large object data is also exempt from the 8,060-byte row limit.
  • クラスター化インデックスのインデックス キーには、ROW_OVERFLOW_DATA アロケーション ユニットに既存のデータを持つ varchar 列を含めることはできません。The index key of a clustered index cannot contain varchar columns that have existing data in the ROW_OVERFLOW_DATA allocation unit. クラスター化インデックスが varchar 列に作成され、既存のデータが IN_ROW_DATA アロケーション ユニットにある場合に、データを行外に押し出すような挿入処理や更新処理をその列に対して行うと失敗します。If a clustered index is created on a varchar column and the existing data is in the IN_ROW_DATA allocation unit, subsequent insert or update actions on the column that would push the data off-row will fail. アロケーション ユニットの詳細については、「テーブルとインデックスの編成」を参照してください。For more information about allocation units, see Table and Index Organization.
  • 行オーバーフロー データを含む列を、非クラスター化インデックスのキー列または非キー列として含めることができます。You can include columns that contain row-overflow data as key or nonkey columns of a nonclustered index.
  • スパース列を使用するテーブルのレコード サイズの制限は 8,018 バイトです。The record-size limit for tables that use sparse columns is 8,018 bytes. 変換したデータに既存のレコード データを加えると 8,018 バイトを超える場合は、MSSQLSERVER ERROR 576 が返されます。When the converted data plus existing record data exceeds 8,018 bytes, MSSQLSERVER ERROR 576 is returned. 列がスパース型と非スパース型の間で変換される場合は、データベース エンジンによって現在のレコード データのコピーが保持されます。When columns are converted between sparse and nonsparse types, Database Engine keeps a copy of the current record data. このため、レコードのために必要なストレージは一時的に 2 倍になります。This temporarily doubles the storage that is required for the record.
  • 行オーバーフロー データを含んでいる可能性のあるテーブルまたはインデックスに関する情報を取得するには、sys.dm_db_index_physical_stats 動的管理関数を使用します。To obtain information about tables or indexes that might contain row-overflow data, use the sys.dm_db_index_physical_stats dynamic management function.

ExtentsExtents

エクステントは、領域を管理する際の基本単位です。Extents are the basic unit in which space is managed. 1 つのエクステントは物理的に連続した 8 ページ、つまり 64 KB です。An extent is eight physically contiguous pages, or 64 KB. したがって、SQL Server データベースには 1 MB あたり 16 のエクステントがあります。This means SQL Server databases have 16 extents per megabyte.

SQL ServerSQL Server には、2 種類のエクステントがあります。has two types of extents:

  • 単一エクステントは、単一のオブジェクトに所有され、所有しているオブジェクトだけがエクステント内の 8 ページすべてを使用できます。Uniform extents are owned by a single object; all eight pages in the extent can only be used by the owning object.
  • 混合エクステントは最大 8 つのオブジェクトによって共有されます。Mixed extents are shared by up to eight objects. エクステント内の各 8 ページを、それぞれ異なるオブジェクトが所有できます。Each of the eight pages in the extent can be owned by a different object.

SQL Server 2014 (12.x)SQL Server 2014 (12.x) までは、SQL ServerSQL Server では、データ量が少ないテーブルにエクステント全体が割り当てられることはありません。Up to, and including, SQL Server 2014 (12.x)SQL Server 2014 (12.x), SQL ServerSQL Server does not allocate whole extents to tables with small amounts of data. 新規テーブルや新規インデックスには、通常、混合エクステントからページが割り当てられます。A new table or index generally allocates pages from mixed extents. そのテーブルやインデックスが 8 ページまで拡張された時点で、その後の割り当てには単一エクステントが使用されるように切り替えられます。When the table or index grows to the point that it has eight pages, it then switches to use uniform extents for subsequent allocations. インデックスに 8 ページ分を生成できるだけの行がある既存のテーブルのインデックスを作成すると、インデックスへのすべての割り当ては単一エクステントになります。If you create an index on an existing table that has enough rows to generate eight pages in the index, all allocations to the index are in uniform extents. ただし、SQL Server 2016 (13.x)SQL Server 2016 (13.x) 以降、データベース内のすべての割り当ての既定値は単一エクステントです。However, starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x), the default for all allocations in the database is uniform extents.

Extents

注意

SQL Server 2014 (12.x)SQL Server 2014 (12.x) までは、トレース フラグ 1118 を使用して、常に単一エクステントを使用するように既定の割り当てを変更できます。Up to, and including, SQL Server 2014 (12.x)SQL Server 2014 (12.x), trace flag 1118 can be used to change the default allocation to always use uniform extents. このトレースフラグの詳細については、「DBCC TRACEON - トレース フラグ」を参照してください。For more information about this trace flag, see DBCC TRACEON - Trace Flags.

SQL Server 2016 (13.x)SQL Server 2016 (13.x) 以降は、TF 1118 によって提供される機能が TempDB に対して自動的に有効になります。Starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x), the functionality provided by TF 1118 is automatically enabled for TempDB. ユーザー データベースの場合、この動作は ALTER DATABASESET MIXED_PAGE_ALLOCATION オプションによって制御され、既定値は OFF に設定され、トレース フラグ 1118 には効果がありません。For user databases, this behavior is controlled by the SET MIXED_PAGE_ALLOCATION option of ALTER DATABASE, with the default value set to OFF, and trace flag 1118 has no effect. 詳細については、「ALTER DATABASE SET オプション (Transact-SQL)」を参照してください。For more information, see ALTER DATABASE SET Options (Transact-SQL).

エクステント割り当てと空き領域の管理Managing Extent Allocations and Free Space

エクステントの割り当てを管理したり、空き領域を追跡したりする SQL ServerSQL Server のデータ構造は、比較的単純です。The SQL ServerSQL Server data structures that manage extent allocations and track free space have a relatively simple structure. このデータ構造には、次の利点があります。This has the following benefits:

  • 空き領域情報は高密度で格納されるので、比較的少数のページに格納できます。The free space information is densely packed, so relatively few pages contain this information.
    このため、割り当て情報の取得に必要なディスク読み取り量が減り、処理が高速化します。This increases speed by reducing the amount of disk reads that are required to retrieve allocation information. また、アロケーション ページがメモリ内にとどまる機会が増え、改めて読み込む必要も少なくなります。This also increases the chance that the allocation pages will remain in memory and not require more reads.

  • 割り当て情報の大部分は相互に連結されていません。Most of the allocation information is not chained together. このため、割り当て情報のメンテナンスが容易になっています。This simplifies the maintenance of the allocation information.
    個々のページの割り当ておよび割り当て解除は迅速に行うことができます。Each page allocation or deallocation can be performed quickly. これにより、ページ割り当てや割り当て解除を必要とする同時実行中のタスク間の競合が減少します。This decreases the contention between concurrent tasks having to allocate or deallocate pages.

エクステント割り当ての管理Managing Extent Allocations

SQL ServerSQL Server は、エクステントの割り当てを記録するために次の 2 種類のアロケーション マップを使用します。uses two types of allocation maps to record the allocation of extents:

  • GAM (Global Allocation Map) Global Allocation Map (GAM)
    GAM ページには、どのエクステントが既に割り当てられているかが記録されます。GAM pages record what extents have been allocated. 1 つの GAM で 64,000 のエクステント、つまり約 4 ギガバイト (GB) のデータが対象となります。Each GAM covers 64,000 extents, or almost 4 gigabytes (GB) of data. GAM では対象とする範囲内のエクステント 1 つにつき 1 ビットが使用されます。The GAM has 1-bit for each extent in the interval it covers. このビットが 1 の場合、そのエクステントは空いており、0 の場合は割り当て済みです。If the bit is 1, the extent is free; if the bit is 0, the extent is allocated.

  • SGAM (Shared Global Allocation Map) Shared Global Allocation Map (SGAM)
    SGAM ページには、混合エクステントとして使用中であり、1 ページ以上が未使用であるエクステントが記録されます。SGAM pages record which extents are currently being used as mixed extents and also have at least one unused page. 1 つの SGAM で 64,000 のエクステント、つまり約 4 GB のデータが対象となります。Each SGAM covers 64,000 extents, or almost 4-GB of data. SGAM では対象とする範囲内のエクステント 1 つにつき 1 ビットが使用されます。The SGAM has 1-bit for each extent in the interval it covers. このビットが 1 の場合、そのエクステントは混合エクステントとして使用されており、空きページが含まれています。If the bit is 1, the extent is being used as a mixed extent and has a free page. ビットが 0 の場合、混合エクステントとして使用されていないエクステントか、すべてのページが使用されている混合エクステントです。If the bit is 0, the extent is not used as a mixed extent, or it is a mixed extent and all its pages are being used.

各エクステントには、現在の使用状況に基づいて GAM および SGAM 内に次のビット パターンが設定されます。Each extent has the following bit patterns set in the GAM and SGAM, based on its current use.

エクステントの現在の使用状況Current use of extent GAM のビット設定GAM bit setting SGAM のビット設定SGAM bit setting
空きがあり、未使用Free, not being used 11 00
単一エクステントであるか、空きページのない混合エクステントUniform extent, or full mixed extent 00 00
空きページがある混合エクステントMixed extent with free pages 00 11

このようなビット パターンの設定により、エクステントの管理アルゴリズムが簡素化されます。This causes simple extent management algorithms.

  • SQL Server データベース エンジンSQL Server Database Engineが単一エクステントを割り当てる際には、GAM の中から 1 のビットを検索し、そのビットを 0 に設定します。To allocate a uniform extent, the SQL Server データベース エンジンSQL Server Database Engine searches the GAM for a 1 bit and sets it to 0.
  • 空きページがある混合エクステントを見つける際には、SQL Server データベース エンジンSQL Server Database Engine は SGAM の中から 1 のビットを検索します。To find a mixed extent with free pages, the SQL Server データベース エンジンSQL Server Database Engine searches the SGAM for a 1 bit.
  • SQL Server データベース エンジンSQL Server Database Engineが混合エクステントを割り当てる際には、GAM の中から 1 のビットを検索してそのビットを 0 に設定し、SGAM 中の対応するビットを 1 に設定します。To allocate a mixed extent, the SQL Server データベース エンジンSQL Server Database Engine searches the GAM for a 1 bit, sets it to 0, and then also sets the corresponding bit in the SGAM to 1.
  • SQL Server データベース エンジンSQL Server Database Engine では、エクステントの割り当てを解除するために、GAM のビットが 1 に、SGAM のビットが 0 に設定されます。To deallocate an extent, the SQL Server データベース エンジンSQL Server Database Engine makes sure that the GAM bit is set to 1 and the SGAM bit is set to 0. SQL Server データベース エンジンSQL Server Database Engine によりデータベース内のデータが均等に分散されるので、実際には、この記事の説明よりもさらに高度なアルゴリズムが SQL Server データベース エンジンSQL Server Database Engine の内部で使用されます。The algorithms that are actually used internally by the SQL Server データベース エンジンSQL Server Database Engine are more sophisticated than what is described in this article, because the SQL Server データベース エンジンSQL Server Database Engine distributes data evenly in a database. この高度なアルゴリズムも、エクステント割り当て情報のチェーンを管理する必要がないので簡素化されています。However, even the real algorithms are simplified by not having to manage chains of extent allocation information.

空き領域の追跡Tracking free space

PFS (Page Free Space) ページには各ページの割り当て状態、個々のページが割り当て済みかどうか、および各ページの空き領域の量が記録されます。Page Free Space (PFS) pages record the allocation status of each page, whether an individual page has been allocated, and the amount of free space on each page. PFS では 1 ページにつき 1 バイトを使用してページが割り当て済みかどうかを示し、割り当て済みの場合はそのページの使用率を 0%、1 ~ 50%、51 ~ 80%、81 ~ 95%、96 ~ 100% の 5 段階で示します。The PFS has 1-byte for each page, recording whether the page is allocated, and if so, whether it is empty, 1 to 50 percent full, 51 to 80 percent full, 81 to 95 percent full, or 96 to 100 percent full.

エクステントがオブジェクトに割り当てられた後は、エクステント内のどのページが割り当て済みでどのページが空いているかをSQL Server データベース エンジンSQL Server Database Engineが PFS ページに記録します。After an extent has been allocated to an object, the SQL Server データベース エンジンSQL Server Database Engine uses the PFS pages to record which pages in the extent are allocated or free. この情報は、SQL Server データベース エンジンSQL Server Database Engineで新しいページを割り当てる必要が生じたときに使用されます。This information is used when the SQL Server データベース エンジンSQL Server Database Engine has to allocate a new page. ページ内の空き領域の量は、ヒープおよび Text/Image ページに関してのみ管理されます。The amount of free space in a page is only maintained for heap and Text/Image pages. SQL Server データベース エンジンSQL Server Database Engineが新しく挿入された行を保持するための空き領域があるページを検索する際に、この情報が使用されます。It is used when the SQL Server データベース エンジンSQL Server Database Engine has to find a page with free space available to hold a newly inserted row. 新しい行を挿入する場所がインデックス キーの値で設定されるので、インデックスは PFS の追跡を必要としません。Indexes do not require that the page free space be tracked, because the point at which to insert a new row is set by the index key values.

PFS ページはデータ ファイル内でファイル ヘッダー ページの直後に位置するページ (ページ ID 1) です。A PFS page is the first page after the file header page in a data file (page ID 1). その次が GAM ページ (ページ ID 2) で、さらに SGAM ページ (ページ ID 3) が続きます。This is followed by a GAM page (page ID 2), and then an SGAM page (page ID 3). 最初の PFS ページの後ろに約 8,000 ページの新しい PFS ページがあり、以降 8,000 ページの間隔で追加の PFS があります。There is a new PFS page approximately 8,000 pages after the first PFS page, and additional PFS pages in subsequent 8,000 page intervals. ページ 2 の最初の GAM ページの後に 64,000 エクステント分の GAM ページがあり、ページ 3 の最初の SGAM ページの後に 64,000 エクステント分の SGAM ページがあり、以降 64,000 エクステントの間隔で追加の GAM ページと SGAM ページがあります。There is another GAM page 64,000 extents after the first GAM page on page 2, another SGAM page 64,000 extents after the first SGAM page on page 3, and additional GAM and SGAM pages in subsequent 64,000 extent intervals. 下図に、SQL Server データベース エンジンSQL Server Database Engineがエクステントの割り当てと管理に使用する一連のページを示します。The following illustration shows the sequence of pages used by the SQL Server データベース エンジンSQL Server Database Engine to allocate and manage extents.

manage_extents

オブジェクトに使用されている領域の管理Managing space used by objects

IAM (Index Allocation Map) 1 ページには、アロケーション ユニットが使用する 4 GB 分のデータベース ファイルのエクステントがマップされます。An Index Allocation Map (IAM) page maps the extents in a 4-GB part of a database file used by an allocation unit. アロケーション ユニットは次の 3 種類のいずれかです。An allocation unit is one of three types:

  • IN_ROW_DATAIN_ROW_DATA
    ヒープまたはインデックスのパーティションを保存します。Holds a partition of a heap or index.

  • LOB_DATALOB_DATA
    ラージ オブジェクト (LOB) データ型 (xml、varbinary(max)、varchar(max) など) を保持します。Holds large object (LOB) data types, such as xml, varbinary(max), and varchar(max).

  • ROW_OVERFLOW_DATAROW_OVERFLOW_DATA
    varchar、nvarchar、varbinary、sql_variant のいずれかの型の、行サイズの上限である 8,060 バイトを超える列に格納された可変長のデータを保存します。Holds variable length data stored in varchar, nvarchar, varbinary, or sql_variant columns that exceed the 8,060 byte row size limit.

ヒープまたはインデックスの各パーティションには、IN_ROW_DATA アロケーション ユニットが必ず含まれています。Each partition of a heap or index contains at least an IN_ROW_DATA allocation unit. ヒープまたはインデックスのスキーマによっては、LOB_DATA アロケーション ユニットまたは ROW_OVERFLOW_DATA アロケーション ユニットが含まれる場合もあります。It may also contain a LOB_DATA or ROW_OVERFLOW_DATA allocation unit, depending on the heap or index schema.

IAM 1 ページで、GAM ページまたは SGAM ページと同じ 4 GB 分のファイルを管理できます。An IAM page covers a 4-GB range in a file and is the same coverage as a GAM or SGAM page. 複数のファイルのエクステントまたは 1 ファイル内でも 4 GB の単位の複数にまたがるエクステントがアロケーション ユニットに含まれている場合、1 つの IAM チェーンに複数の IAM ページがリンクされます。If the allocation unit contains extents from more than one file, or more than one 4-GB range of a file, there will be multiple IAM pages linked in an IAM chain. したがって、各アロケーション ユニットには、含まれているエクステントが所属するファイル 1 つについて、IAM が少なくとも 1 ページ存在します。Therefore, each allocation unit has at least one IAM page for each file on which it has extents. アロケーション ユニットに割り当てられているファイルのエクステントの範囲が 1 ページの IAM に記録できる範囲を超えている場合、1 つのファイルに複数の IAM ページが存在する場合もあります。There may also be more than one IAM page on a file, if the range of the extents on the file allocated to the allocation unit exceeds the range that a single IAM page can record.

iam_pages

IAM ページはアロケーション ユニットごとに必要に応じて割り当てられ、そのファイル内での配置はランダムです。IAM pages are allocated as required for each allocation unit and are located randomly in the file. アロケーション ユニットの最初の IAM ページはシステム ビュー sys.system_internals_allocation_units のポインターが指しています。The system view, sys.system_internals_allocation_units, points to the first IAM page for an allocation unit. アロケーション ユニットのすべての IAM ページは 1 つのチェーンにリンクされています。All the IAM pages for that allocation unit are linked in a chain.

重要

sys.system_internals_allocation_units システム ビューは内部専用であり、変更されることがあります。The sys.system_internals_allocation_units system view is for internal use only and is subject to change. 互換性は保証されません。Compatibility is not guaranteed.

iam_chain

アロケーション ユニットのチェーンにリンクされている IAM ページIAM ページには、その IAM ページによってマップされるエクステントの範囲の開始エクステントを示すヘッダーがあります。IAM pages linked in a chain per allocation unit An IAM page has a header that indicates the starting extent of the range of extents mapped by the IAM page. また、1 ビットが 1 つのエクステントを表す大きな 1 つのビットマップがあります。The IAM page also has a large bitmap in which each bit represents one extent. マップ内の最初のビットは、その範囲で最初のエクステントを表し、2 番目のビットは第 2 エクステントを表し、それ以降のビットも同様の順でエクステントを表します。The first bit in the map represents the first extent in the range, the second bit represents the second extent, and so on. ビットが 0 の場合、そのビットが表すエクステントは、IAM を所有するアロケーション ユニットに割り当てられていません。If a bit is 0, the extent it represents is not allocated to the allocation unit owning the IAM. ビットが 1 の場合、そのビットが表すエクステントは、IAM ページを所有するアロケーション ユニットに割り当てられています。If the bit is 1, the extent it represents is allocated to the allocation unit owning the IAM page.

新しい行を挿入する必要があるのに現在のページに使用できる領域がない場合、SQL Server データベース エンジンSQL Server Database Engineでは IAM ページおよび PFS ページで割り当てのためのページを検索するか、ヒープあるいは Text 型または Image 型のページについては行を格納するのに必要な空き領域があるページを検索します。When the SQL Server データベース エンジンSQL Server Database Engine has to insert a new row and no space is available in the current page, it uses the IAM and PFS pages to find a page to allocate, or, for a heap or a Text/Image page, a page with sufficient space to hold the row. まず、SQL Server データベース エンジンSQL Server Database Engineは IAM ページを使用してそのアロケーション ユニットに割り当てられているエクステントを検索します。The SQL Server データベース エンジンSQL Server Database Engine uses the IAM pages to find the extents allocated to the allocation unit. それぞれのエクステントについて、SQL Server データベース エンジンSQL Server Database Engineは使用可能なページがあるかどうかを PFS ページの中で検索します。For each extent, the SQL Server データベース エンジンSQL Server Database Engine searches the PFS pages to see if there is a page that can be used. IAM ページおよび PFS ページは 1 ページで多数のデータ ページを管理できるので、データベース内の IAM ページおよび PFS ページの数はわずかです。Each IAM and PFS page covers lots of data pages, so there are few IAM and PFS pages in a database. このため、IAM ページおよび PFS ページは一般的に SQL ServerSQL Server バッファー プールのメモリに入っており、高速に検索できます。This means that the IAM and PFS pages are generally in memory in the SQL ServerSQL Server buffer pool, so they can be searched quickly. インデックスの場合、新しい行の挿入ポイントがインデックス キーによって設定されるが、新しいページが必要なときは、前述のプロセスが発生します。For indexes, the insertion point of a new row is set by the index key, but when a new page is needed, the previously described process occurs.

SQL Server データベース エンジンSQL Server Database Engineによりアロケーション ユニットに新しいエクステントが割り当てられるのは、挿入する行を格納するのに必要な空き領域のあるページが既存のエクステントの中ですぐに見つからない場合のみです。The SQL Server データベース エンジンSQL Server Database Engine allocates a new extent to an allocation unit only when it cannot quickly find a page in an existing extent with sufficient space to hold the row being inserted.

SQL Server データベース エンジンSQL Server Database Engine比例配分割り当てアルゴリズムを使用して、ファイル グループ内の利用可能なエクステントからエクステントを割り当てます。The SQL Server データベース エンジンSQL Server Database Engine allocates extents from those available in the filegroup using a proportional fill allocation algorithm. 同じファイル グループに 2 つのファイルがあり、一方のファイルにもう一方の 2 倍の空き領域がある場合は、空きが少ないファイルから 1 ページ割り当てられるごとに、空きが多いファイルからは 2 ページが割り当てられます。If in the same filegroup with two files, one file has two times the free space as the other, two pages will be allocated from the file with the available space for every one page allocated from the other file. したがって、ファイル グループ内のすべてのファイルは、使用済み領域のパーセンテージがほとんど同じになります。This means that every file in a filegroup should have a similar percentage of space used.

変更されたエクステントの追跡Tracking Modified Extents

SQL ServerSQL Server では、一括コピー操作によって変更されたか、または最後の完全バックアップによって変更されたエクステントを追跡するために、2 つの内部データ構造を使用します。uses two internal data structures to track extents modified by bulk copy operations and extents modified since the last full backup. これらのデータ構造により、差分バックアップの処理速度が大幅に向上します。These data structures greatly speed up differential backups. また、データベースで一括ログ復旧モデルを使用している場合は、一括ログ コピー操作の速度も向上します。They also speed up the logging of bulk copy operations when a database is using the bulk-logged recovery model. GAM (グローバル アロケーション マップ) ページや SGAM (共有グローバル アロケーション マップ) ページと同様に、これらの構造はビットマップで、各ビットが 1 つのエクステントを表します。Like the Global Allocation Map (GAM) and Shared Global Allocation Map (SGAM) pages, these structures are bitmaps in which each bit represents a single extent.

  • DCM (差分変更マップ) Differential Changed Map (DCM)
    最後の BACKUP DATABASE ステートメント以降に変更されたエクステントが追跡されます。This tracks the extents that have changed since the last BACKUP DATABASE statement. エクステントのビットが 1 の場合、そのエクステントは最後の BACKUP DATABASE ステートメント以降に変更されています。If the bit for an extent is 1, the extent has been modified since the last BACKUP DATABASE statement. このビットが 0 の場合、エクステントは変更されていません。If the bit is 0, the extent has not been modified. 差分バックアップでは、DCM ページを読み取るだけで、変更されているエクステントを判断します。Differential backups read just the DCM pages to determine which extents have been modified. これにより、差分バックアップでスキャンしなければならないページの数が大幅に削減されます。This greatly reduces the number of pages that a differential backup must scan. 差分バックアップを実行するときの時間の長さは、最後の BACKUP DATABASE ステートメント以降に変更されたエクステントの数に比例し、データベースの全体的なサイズには比例しません。The length of time that a differential backup runs is proportional to the number of extents modified since the last BACKUP DATABASE statement and not the overall size of the database.

  • BCM (一括変更マップ) Bulk Changed Map (BCM)
    最後の BACKUP LOG ステートメント以降に、一括ログ記録操作によって変更されたエクステントが追跡されます。This tracks the extents that have been modified by bulk logged operations since the last BACKUP LOG statement. エクステントのビットが 1 の場合、そのエクステントは最後の BACKUP LOG ステートメント以降に一括ログ記録操作によって変更されています。If the bit for an extent is 1, the extent has been modified by a bulk logged operation after the last BACKUP LOG statement. このビットが 0 の場合、一括ログ記録操作によってエクステントは変更されていません。If the bit is 0, the extent has not been modified by bulk logged operations. BCM ページはすべてのデータベースにありますが、データベースで一括ログ復旧モデルを使用している場合にのみ使用します。Although BCM pages appear in all databases, they are only relevant when the database is using the bulk-logged recovery model. この復旧モデルでは、BACKUP LOG を実行するときにバックアップ プロセスで BCM をスキャンし、変更されたエクステントを探します。In this recovery model, when a BACKUP LOG is performed, the backup process scans the BCMs for extents that have been modified. その後、これらのエクステントをログ バックアップに含めます。It then includes those extents in the log backup. これにより、データベースがデータベース バックアップと、トランザクション ログ バックアップのシーケンスから復元される場合に、一括ログ記録操作を復旧できます。This lets the bulk logged operations be recovered if the database is restored from a database backup and a sequence of transaction log backups. 一括ログ記録操作はログに記録されないので、BCM ページは単純復旧モデルを使用しているデータベースには関係しません。BCM pages are not relevant in a database that is using the simple recovery model, because no bulk logged operations are logged. 完全復旧モデルでは一括ログ記録操作が完全にログに記録された操作として扱われるので、BCM ページは完全復旧モデルを使用するデータベースにも関係しません。They are not relevant in a database that is using the full recovery model, because that recovery model treats bulk logged operations as fully logged operations.

DCM ページと BCM ページ間の間隔は、GAM ページと SGAM ページの間隔と同じで 64,000 エクステントです。The interval between DCM pages and BCM pages is the same as the interval between GAM and SGAM page, 64,000 extents. DCM ページと BCM ページは、物理ファイル内の GAM ページと SGAM ページの後に配置されます。The DCM and BCM pages are located behind the GAM and SGAM pages in a physical file:

special_page_order

参照See Also

sys.allocation_units (Transact-SQL) sys.allocation_units (Transact-SQL)
ヒープ (クラスター化インデックスなしのテーブル) Heaps (Tables without Clustered Indexes)
ページの読み取り Reading Pages
ページの書き込みWriting Pages