インメモリOLTPチェックポイント操作に関する統計を出力する：SQL Server動的管理ビューレファレンス（125）

「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「動的管理ビュー」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は、インメモリOLTPチェックポイント操作に関する統計を出力する方法について解説します。

[伊東敏章，＠IT]

SQL Server動的管理ビュー一覧

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で使用可能な動的管理ビューについて、動作概要や出力内容などを紹介していきます。今回は動的管理ビュー「sys.dm_db_xtp_checkpoint_stats」における、インメモリOLTPチェックポイント操作に関する統計を出力する方法について解説します。対応バージョンは、SQL Server（サポートされている全てのバージョン）、「Azure SQL Database」「Azure SQL Managed Instance」です。

概要

　SQL Serverでは、インメモリOLTPを使用することで、トランザクション処理やデータ取得、データロード、一時データ・シナリオのパフォーマンスを最適化できます。インメモリOLTPでは、データアクセスやトランザクションの実行は、従来のディスクベースのオブジェクトとは異なるアルゴリズムで処理されます。

　インメモリOLTPでは、従来のディスクベースのテーブルと同様に定期的にチェックポイントが発生し、トランザクションログのアクティブな部分が更新されます。インメモリOLTPにおけるチェックポイントは、従来のチェックポイントとは実装が異なり、自動チェックポイントは異なったタイミングで実行されます。

　「sys.dm_db_xtp_checkpoint_stats」動的管理ビューを使用することで、インメモリOLTPチェックポイントの実行状況に関する情報を出力できます。

• sys.dm_db_xtp_checkpoint_stats（Transact-SQL）
• メモリ最適化テーブルのチェックポイント操作

出力内容

　「sys.dm_db_xtp_checkpoint_stats」は、SQL Server 2014以前と、SQL Server 2016以降とで出力内容が大幅に異なります。下記は、SQL Server 2016以降での出力内容です。

列名	データ型	説明
last_lsn_processed	bigint	コントローラーが認識した最後のLSN（Log Sequence Number）
end_of_log_lsn	numeric（38）	ログの末尾のLSN
bytes_to_end_of_log	bigint	コントローラーによって処理されていないバイト数 「last_lsn_processed」と「end_of_log_lsn」との間のバイト数に相当する
log_consumption_rate	bigint	コントローラーによるトランザクションログの使用率（KB／秒）
active_scan_time_in_ms	bigint	トランザクションログをアクティブにスキャンするためにコントローラーによって費やされた時間
total_wait_time_in_ms	bigint	ログをスキャンしていないときの、コントローラーの累積待機時間
waits_for_io	bigint	コントローラースレッドによって発生したログI/Oの待機の数
io_wait_time_in_ms	bigint	コントローラースレッドによって発生したログI/Oの待機に費やされた累積時間
waits_for_new_log_count	bigint	コントローラースレッドによって発生した新しいログの待機数
new_log_wait_time_in_ms	bigint	コントローラースレッドによって発生した新しいログの待機に費やされた累積時間
idle_attempts_count	bigint	コントローラーがアイドル状態に遷移した回数
tx_segments_dispatched	bigint	コントローラーによって認識され、シリアライザーにディスパッチされたセグメントの数 セグメントはシリアル化の単位を形成するログの連続部分。現在のサイズは1MBに設定されているが、将来変更される可能性がある
segment_bytes_dispatched	bigint	データベースの再起動後に、コントローラーによってシリアライザーにディスパッチされた合計バイト数
bytes_serialized	bigint	データベースの再起動後にシリアル化された合計バイト数
serializer_user_time_in_ms	bigint	ユーザーモードでシリアライザーによって費やされた時間
serializer_kernel_time_in_ms	bigint	カーネルモードでシリアライザーに費やされた時間
xtp_log_bytes_consumed	bigint	データベースの再起動後に使用されたログのバイト数の合計
checkpoints_closed	bigint	データベースの再起動以降に閉じられたチェックポイントの数
last_closed_checkpoint_ts	bigint	最後に閉じられたチェックポイントのタイムスタンプ
hardened_recovery_lsn	numeric（38）	復旧が開始されるLSN
hardened_root_file_guid	uniqueidentifier	最後に完了したチェックポイントの結果として書き込まれたルートファイルのGUID
hardened_root_file_watermark	bigint	内部のみ。ルートファイルをどこまで読み取ることができるか（これは、内部的に関連する型のみのBSNと呼ばれる）
hardened_truncation_lsn	numeric（38）	切り捨てポイントのLSN
log_bytes_since_last_close	bigint	最後のログから現在のログの最後までのバイト数
time_since_last_close_in_ms	bigint	チェックポイントが最後に閉じられてからの時間
current_checkpoint_id	bigint	現在、このチェックポイントに新しいセグメントが割り当てられている。チェックポイントシステムはパイプライン。現在のチェックポイントは、ログのセグメントが割り当てられているチェックポイント。制限に達すると、チェックポイントはコントローラーによって解放され、新しいチェックポイントが現在のものとして作成される
current_checkpoint_segment_count	bigint	現在のチェックポイント内のセグメントの数
recovery_lsn_candidate	bigint	内部のみ 「current_checkpoint_id」が閉じるときに「recoverylsn」として選択される候補
outstanding_checkpoint_count	bigint	終了を待機しているパイプライン内のチェックポイントの数
closing_checkpoint_id	bigint	終了チェックポイントのID シリアライザーは並行して動作しているため、完了すると、チェックポイントはクローズスレッドによって閉じられる候補になる。ただし、クローズスレッドは一度に1つだけを閉じることができ、順番に閉じなければならないので、クローズスレッドが処理しているチェックポイントが閉じられる
recovery_checkpoint_id	bigint	リカバリーに使用するチェックポイントのID
recovery_checkpoint_ts	bigint	リカバリーチェックポイントのタイムスタンプ
bootstrap_recovery_lsn	numeric（38）	ブートストラップの復旧LSN
bootstrap_root_file_guid	uniqueidentifier	ブートストラップのルートファイルのGUID
internal_error_code	bigint	コントローラーやシリアライザー、クローズ、マージスレッドによって発生したエラー
bytes_of_large_data_serialized	bigint	シリアル化されたデータの量

動作例

　データベースでインメモリOLTPを構成し、メモリ最適化テーブルの作成とデータの挿入を行った後に、「sys.dm_db_xtp_checkpoint_stats」動的管理ビューを出力しました（図1）。

図1　「sys.dm_db_xtp_checkpoint_stats」」動的管理ビューを出力したところ

　しばらくメモリ最適化テーブルのデータ更新を大量に繰り返した後に、もう一度、「sys.dm_db_xtp_checkpoint_stats」動的管理ビューを出力しました（図2）。

図2　データ更新を繰り返した後に「sys.dm_db_xtp_checkpoint_stats」動的管理ビューを出力したところ

　チェックポイント処理されたLSNが進んでいることや、チェックポイント処理によるログ書き込みの状況などを確認できました。

※本Tipsは、「Windows Server 2019」上に「SQL Server 2019」をインストールした環境を想定して解説しています。

筆者紹介

椎名 武史（しいな たけし）

BIPROGY株式会社（ビプロジー）所属。Microsoft MVP for Data Platform（2017〜）。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。

伊東 敏章（いとう としあき）

BIPROGY株式会社（ビプロジー）所属。入社以来SQL Server一筋で評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。社内のプログラミングコンテストで4回の優勝経験も持つ。趣味は輪行で週末は自転車を持っての旅行。目標は色々な日本百選を制覇すること。