ページの書き込みWriting Pages

適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics はいParallel Data WarehouseParallel Data WarehouseyesParallel Data WarehouseParallel Data Warehouse適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics はいParallel Data WarehouseParallel Data WarehouseyesParallel Data WarehouseParallel Data Warehouse

データベース エンジンDatabase Engine のインスタンスからの I/O には論理書き込みと物理書き込みがあります。The I/O from an instance of the データベース エンジンDatabase Engine includes logical and physical writes. 論理書き込みは、バッファー キャッシュ内のページのデータが変更されるときに行われます。A logical write occurs when data is modified in a page in the buffer cache. 物理書き込みは、そのページを バッファー キャッシュ からディスクに書き込むときに行われます。A physical write occurs when the page is written from the buffer cache to disk.

ページがバッファー キャッシュ内で変更されたとき、その変更が直ちにディスクに書き戻されるわけではありません。代わりに、そのページはダーティとマークされます。When a page is modified in the buffer cache, it is not immediately written back to disk; instead, the page is marked as dirty. これはページが物理的にディスクに書き込まれる前に複数回の論理書き込みが行われていることを意味します。This means that a page can have more than one logical write made before it is physically written to disk. 論理書き込みを行うたびに、トランザクション ログ レコードが、変更を記録するログ キャッシュに挿入されます。For each logical write, a transaction log record is inserted in the log cache that records the modification. ログ レコードは、関連付けられているダーティ ページがバッファー キャッシュから削除されディスクに書き込まれる前に、ディスクに書き込まれる必要があります。The log records must be written to disk before the associated dirty page is removed from the buffer cache and written to disk. SQL Server では、先行書き込みログと呼ばれている手法が利用され、関連ログ レコードがディスクに書き込まれる前にダーティ ページが書き込まれることを防止します。SQL Server uses a technique known as write-ahead logging that prevents writing a dirty page before the associated log record is written to disk. これは復旧マネージャーが正しく機能するために必要不可欠です。This is essential to the correct working of the recovery manager. 詳細については、「 先行書き込みトランザクション ログ」を参照してください。For more information, see Write-Ahead Transaction Log.

次の図は、変更されたデータ ページが書き込まれるプロセスを示しています。The following illustration shows the process for writing a modified data page.

Writing_Pages

バッファー マネージャーでは、ページを書き込むときに、1 回のギャザー書き込み操作に含めることができる隣接するダーティ ページを検索します。When the buffer manager writes a page, it searches for adjacent dirty pages that can be included in a single gather-write operation. 隣接するページとは、ページ ID が連続していて、同じファイルに含まれているページです。メモリ内で連続している必要はありません。Adjacent pages have consecutive page IDs and are from the same file; the pages do not have to be contiguous in memory. 検索は、次に示すいずれかの状況が発生するまで、前後両方向に続行されます。The search continues both forward and backward until one of the following events occurs:

  • クリーンなページが見つかった。A clean page is found.
  • 32 ページ分見つかった。32 pages have been found.
  • ログ内でまだフラッシュされていないログ シーケンス番号 (LSN) を含むダーティ ページが見つかった。A dirty page is found whose log sequence number (LSN) has not yet been flushed in the log.
  • 直ちにラッチできないページが見つかった。A page is found that cannot be immediately latched.

このようにして、ページのセット全体を 1 回のギャザー書き操作でディスクに書き込むことができます。In this way, the entire set of pages can be written to disk with a single gather-write operation.

ページが書き込まれる直前に、データベースで指定されたページ保護の形式が、ページに追加されます。Just before a page is written, the form of page protection specified in the database is added to the page. 破損ページ保護が追加される場合、I/O に対してそのページを排他的にラッチする必要があります。If torn page protection is added, the page must be latched EX(clusively) for the I/O. これは、破損ページ保護によってページが変更された結果、他のスレッドから読み取るのに不適切な形式となるためです。This is because the torn page protection modifies the page, making it unsuitable for any other thread to read. チェックサム ページ保護が追加される場合、またはデータベースがページ保護を使用していない場合は、I/O に対してそのページを更新 (UP) ラッチでラッチします。If checksum page protection is added, or the database uses no page protection, the page is latched with an UP(date) latch for the I/O. このラッチでは、書き込み中は他からのページ変更を防ぎますが、読み取りは許可します。This latch prevents anyone else from modifying the page during the write, but still allows readers to use it. ディスク I/O のページ保護オプションの詳細については、「 バッファー管理」を参照してください。For more information about disk I/O page protection options, see Buffer Management.

ダーティ ベージは次の 3 つの方法のいずれかでディスクに書き込まれます。A dirty page is written to disk in one of three ways:

  • レイジー書き込みLazy writing
    レイジー ライターは、使用頻度の少ないページをバッファー キャッシュから削除することで空きバッファーを使用可能にするシステム プロセスです。The lazy writer is a system process that keeps free buffers available by removing infrequently used pages from the buffer cache. ダーティ ページが最初にディスクに書き込まれます。Dirty pages are first written to disk.

  • 集中書き込みEager writing
    集中書き込みプロセスでは、一括挿入や SELECT INTO 操作など、ログに最小限記録される操作に関連付けられているダーティ データ ページを書き込みます。The eager write process writes dirty data pages associated with minimally logged operations such as bulk insert and select into. このプロセスにより、新しいページの作成と書き込みを並列に実行できます。This process allows creating and writing new pages to take place in parallel. つまり、ページからディスクへの書き込み操作全体が完了するまで呼び出し操作が待機する必要はありません。That is, the calling operation does not have to wait until the entire operation finishes before writing the pages to disk.

  • CheckpointCheckpoint
    チェックポイント プロセスでは、指定されたデータベースからのページを含むバッファーのバッファー キャッシュを定期的にスキャンし、ダーティ ページをすべてディスクに書き込みます。The checkpoint process periodically scans the buffer cache for buffers with pages from a specified database and writes all dirty pages to disk. チェックポイントは、すべてのダーティ ページがディスクに書き込まれたことを確認するために作成されるポイントで、その後の復旧の時間を短縮します。Checkpoints save time during a later recovery by creating a point at which all dirty pages are guaranteed to have been written to disk. ユーザーは、CHECKPOINT コマンドを使用することでチェックポイント操作を要求できます。または、使用済みのログ容量と最後にチェックポイント操作が行われてからの経過時間に基づいて、 データベース エンジンDatabase Engine によって自動的にチェックポイントが生成される場合もあります。The user may request a checkpoint operation by using the CHECKPOINT command, or the データベース エンジンDatabase Engine may generate automatic checkpoints based on the amount of log space used and time elapsed since the last checkpoint. さらに、特定の利用状況が発生したときに、チェックポイントが生成されます。In addition, a checkpoint is generated when certain activities occur. たとえば、データ ファイルやログ ファイルがデータベースに追加されたり、データベースから削除されたりするとき、または SQL Server インスタンスが停止したときなどです。For example, when a data or log file is added or removed from a database, or when the instance of SQL Server is stopped. 詳細については、「 チェックポイントとログのアクティブな部分」を参照してください。For more information, see Checkpoints and the Active Portion of the Log.

レイジー書き込み、集中書き込み、チェックポイント プロセスは I/O 操作の完了を待機しません。The lazy writing, eager writing, and checkpoint processes do not wait for the I/O operation to complete. これらは、常に、非同期 (重複) I/O を使用し、他の作業と並列して続行され、I/O の成功は後でチェックします。They always use asynchronous (or overlapped) I/O and continue with other work, checking for I/O success later. このため、SQL Server では CPU リソースと I/O リソースの両方を適切なタスクに最大限に利用できます。This allows SQL Server to maximize both CPU and I/O resources for the appropriate tasks.

参照See Also

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