SQLServerのデータベースチェックポイント

この記事では、SQLServerチェックポイントについて説明します。

パフォーマンスを向上させるために、SQLServerはメモリ内のデータベースページに変更を適用します。多くの場合、このメモリはバッファキャッシュまたはバッファプールと呼ばれます。 SQL Serverは、変更のたびにこれらのページをディスクにフラッシュしません。代わりに、データベースエンジンは、各データベースに対して随時チェックポイント操作を実行します。 チェックポイント 操作はダーティページ（現在のメモリ内で変更されたページ）を書き込み、トランザクションログに関する詳細も書き込みます。

SQL Serverは、次の4種類のチェックポイントをサポートしています。

1。自動— このタイプのチェックポイントはバックグラウンドで発生し、リカバリ間隔サーバーの構成によって異なります。値は分単位で測定され、デフォルト値は1分です（これより低く設定することはできません）。チェックポイントは、パフォーマンスへの影響を最小限に抑える時間内に完了します。

EXEC sp_configure 'recovery interval', 'seconds'

SIMPLEリカバリモデルでは、トランザクションログが70％いっぱいになると、自動チェックポイントもトリガーされます。

2。間接的— このタイプのチェックポイントは、ユーザー指定のデータベース回復時間設定に従って、バックグラウンドでも発生します。 SQL Server 2016 CTP2以降、このタイプのチェックポイントのデフォルト値は1分です。これは、データベースが間接チェックポイントを使用することを意味します。古いバージョンのSQLServerの場合、デフォルトは0です。これは、データベースが自動チェックポイントを使用することを意味します。その頻度は、SQLServerインスタンスの回復間隔設定によって異なります。 Microsoftは、ほとんどのシステムで1分を推奨しています。

ALTER DATABASE … SET TARGET_RECOVERY_TIME =
target_recovery_time { SECONDS | MINUTES }

これを設定するときは、基盤となるI/Oサブシステムの機能を考慮してください。 I / Oサブシステム（SSDなど）を高速化するには、これを低く設定することをお勧めします。この設定はバックアップと復元を通じて維持されるため、低速のハードウェアに復元すると、I/O負荷が大きすぎるためにパフォーマンスの問題が発生する可能性があることに注意してください。

3。手動— T-SQLCHECKPOINTコマンドの実行中に発生します。

CHECKPOINT [ checkpoint_duration ]

checkpoint_duration チェックポイントが完了する必要がある時間を定義するために使用される整数です。このパラメーターは、チェックポイント操作に割り当てられるリソースの数も管理します。パラメータが指定されていない場合、パフォーマンスへの影響を最小限に抑える時間内にチェックポイントが完了します。

4。内部— 一部のSQLServer操作では、このタイプのチェックポイントを発行して、ディスクイメージが現在のトランザクションログの状態と一致することを確認します。これらは、特定の操作が行われたときに実行されるチェックポイントです。

データファイルが追加または削除されます
データベースのシャットダウンが発生します（何らかの理由で）
バックアップまたはデータベースのスナップショットが作成されます
非表示のデータベーススナップショット（またはDBCC_CHECKDB、DBCC_CHECKTABLEなど）を作成するDBCCコマンドが実行されます。

チェックポイントが役立つのはなぜですか？

チェックポイントにより、クラッシュリカバリ時間が短縮されます。 これは、データファイルページがログレコードと同時にディスクに書き込まれないために発生します。ディスク上のデータファイルページよりも最新のデータファイルページがメモリ内にあります。

チェックポイントにより、ディスクへのI / Oが削減され、パフォーマンスが向上します。 トランザクションのコミット時にデータファイルページがディスクに書き込まれない理由は、I/O操作の数を減らすためです。 1つのデータページに対する数千のUPDATEトランザクションを想像してみてください。データページをディスクに書き込むのは、変更するたびに行うよりも、チェックポイント中に1回だけ行う方が効率的です。

きれいで汚れたページ

バッファプールは、メモリ内に多数のデータページを保持します。データページには2つのタイプがあります：クリーン およびダーティ 。クリーンページとは、ディスクからの最後の読み取りまたはディスクへの書き込み以降に変更されていないページです。ダーティページとは、変更されたページであり、変更がディスクに書き込まれていません。チェックポイントは「ダーティページ」を指します。

このページに関する情報は、 sys.dm_os_buffer_descriptorsを使用して確認できます。。この関数が何を返すか見てみましょう：

SELECT
  *
FROM sys.dm_os_buffer_descriptors dobd;
GO

各ページには、ページの状態を追跡する制御構造が関連付けられています。

datdabase_id 32767を持つデータベースは、すべてのシステムオブジェクトを含む読み取り専用のリソースデータベースです。
file_id 、 page_id 、 alllocation_unit_id そのページはに属します。
データページまたはインデックスページのいずれかのページです。
ページの行数。
ページの空き容量
ページが汚れているかどうか
特定のページが属するnuma_node
最近使用されたアルゴリズムに関する情報

次のコードを使用して、この情報をデータベースごとに集約してみましょう。

SELECT
  *,
  [DirtyPageCount] * 8 / 1024 AS [DirtyPageMB],
  [CleanPageCount] * 8 / 1024 AS [CleanPageMB]
FROM (SELECT
  (CASE
    WHEN ([database_id] = 32767) THEN N'Resource Database'
    ELSE DB_NAME([database_id])
  END) AS [DatabaseName],
  SUM(CASE
    WHEN ([is_modified] = 1) THEN 1
    ELSE 0
  END) AS [DirtyPageCount],
  SUM(CASE
    WHEN ([is_modified] = 1) THEN 0
    ELSE 1
  END) AS [CleanPageCount]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id]) AS [buffers]
ORDER BY [DatabaseName]
GO

チェックポイントメカニズム

チェックポイントが発生すると、すべてのダーティページがディスクに書き込まれます。いくつかの変更があるとすぐに、ページがダーティとしてマークされます。チェックポイントの時点で、変更を行ったトランザクションがコミットされているか、コミットされていないかは関係ありません。ページがディスクに書き込まれた後、「ダーティ」ビットはクリアされます。チェックポイントが発生すると、次のアクションが実行されます。

新しいログレコードは、チェックポイントの開始を示します
追加のログレコードは、チェックポイント情報（チェックポイントが開始されたときのトランザクションログの状態など）とともに表示されます
すべてのダーティページはディスクに書き込まれます
データベースブートページ（dbi_checkptLSN内）でチェックポイントのLSNをマークします。これは、クラッシュリカバリにとって重要です
SIMPLEリカバリモデルを使用している場合は、ログをクリアしてみてください
最終的なログレコードは、チェックポイントが完了したことを示します

複数のデータベースのチェックポイントが並行して発生する可能性があります。 SQL Server 2000は、一度に1つのチェックポイントに制限されていました。バッファマネージャがページを書き込むとき、単一の収集書き込み操作に含めることができる隣接するダーティページを検索します。また、バッファプールは、I/Oサブシステムに過負荷がかからないようにしようとします。 I/Oが完了するまでにかかる時間を追跡します。チェックポイント中に書き込みレイテンシが20ミリ秒を超えると、それ自体が抑制されます。シャットダウン中、スロットルしきい値は100ミリ秒に増加します。詳細な説明はここにあります。文書化されていない「-kXX」起動オプションを使用して、チェックポイントI/OレートをXXMB/秒に設定できます。

データファイルページがチェックポイントによってディスクに書き込まれる場合、先行書き込みログは、そのページに影響を与えるすべてのログレコードが最初にディスク上のトランザクションログに書き込まれる必要があることを保証します。ページに影響を与えた最後のログレコードまでのすべてのログレコードは、それらがどのトランザクションに含まれているかに関係なく、書き出されます。ログレコードは、次の3つの方法で書き出されます。

トランザクションがコミットまたは中止されたとき
データファイルページがディスクに書き込まれるとき
ログブロックが最大サイズの60KBに達し、強制的に終了した場合

チェックポイントログレコード

チェックポイントは、トランザクションログに複数のログレコードを書き込みます：

LOP_BEGIN_CKPT —チェックポイントが開始されたことを示します
LOP_XACT_CKPT NULLコンテキスト（チェックポイントの開始時にコミットされていないトランザクションがある場合のみ）—コミットされていないトランザクションの数のカウントが含まれます。また、コミットされていないトランザクションのLOP_BEGIN_XACTログレコードのLSNも一覧表示されます。
LOP_BEGIN_CKPT LOP_BOOT_PAGE_CKPTのコンテキスト（SQL Server 2012のみ）—ブートページが更新されたことを示します。
LOP_END_CKPT —チェックポイントの終了を示します。

チェックポイントの監視

I / Oのスパイクで発生するチェックポイントを相関させて、特定のデータベース（I / Oサブシステム用）に変更を加えて、I/Oサブシステムが過負荷になった場合のI/Oスパイクを軽減できると便利です。たとえば、SQL Server 2012で間接チェックポイントを使用して、より頻繁に手動チェックポイントを実行したり、より短い回復間隔を構成したりします。これにより、I/Oサブシステムに過負荷をかける高いスパイクなしでより一定したI/O負荷が生成されます。ただし、根本的な原因は、どこかで変更が発生したために実行されるI / Oが増えることである可能性があるため、チェックポイントアクティビティの突然の増加を、それが発生した理由を調査せずに受け入れるだけではいけません。

バッファマネージャ/チェックポイントページ/秒カウンタはデータベース固有ではないため、関係するデータベースを特定するには、トレースフラグまたは拡張イベントが必要です。

トレースフラグ3502 データベースチェックポイントが発生しているエラーログにメッセージを書き込みます。

トレースフラグ3504 書き出されたページ数と平均書き込み待ち時間に関するより詳細な情報を書き込みます。

これらのトレースフラグは、限られた石灰の生産で安全に使用できます。エラーログにメッセージを出力するだけです。

拡張イベントを使用する場合は、checkpoint_beginとcheckpoint_endの2つのイベントを使用できます。

概要

この記事では、SQL Serverのチェックポイントについて説明しました。これは、データファイルページが変更された後にディスクに書き込むための主要なメカニズムです。