データベース チェックポイント (SQL Server)
このトピックでは、SQL Server データベース チェックポイントの概要について説明します。 "チェックポイント" によって、予期しないシャットダウンやクラッシュの後の復旧中に、ログに格納されている変更を SQL Server データベース エンジンが適用するための最適なポイントが作成されます。
チェックポイントの概要
パフォーマンス上の理由から、データベース エンジンはバッファー キャッシュ内のメモリ内のデータベース ページに対して変更を実行し、変更のたびにこれらのページをディスクに書き込むことはありません。 代わりに、データベース エンジンでは定期的に各データベースに "チェックポイント" が発行されます。 チェックポイント では、現在メモリにある修正ページ (つまり ダーティ ページ) とトランザクション ログ情報がメモリからディスクに書き込まれ、トランザクション ログの情報も記録されます。
データベース エンジンでは、自動、間接、手動、内部などいくつかのチェックポイントの種類がサポートされています。 次の表は、チェックポイントの種類をまとめたものです。
| 名前 | Transact-SQL インターフェイス | 説明 |
|---|---|---|
| 自動 | EXEC sp_configure 'recovery interval','seconds |
サーバー構成オプションで推奨される上限を満たすために、バックグラウンドで自動的に recovery interval 発行されます。 自動チェックポイントは、最後まで実行されます。 自動チェックポイントは、未処理の書き込みの数と、データベース エンジンが 20 ミリ秒を超える書き込み待機時間の増加を検出したかどうかに基づいて調整されます。詳細については、「 recovery interval サーバー構成オプションの構成」を参照してください。 |
| 間接 | ALTER DATABASE ...SET TARGET_RECOVERY_TIME =target_recovery_time { SECONDS |MINUTES } | 所定のデータベースのユーザーが指定したターゲット復旧時間に合わせて、バック グラウンドで発行されます。 既定のターゲット復旧時間は 0 です。この場合、自動チェックポイント ヒューリスティックがデータベースで使用されます。 ALTER DATABASE を使用して TARGET_RECOVERY_TIME を 0 に設定した場合は、サーバー インスタンスに >指定された復旧間隔ではなく、この値が使用されます。 詳細については、「データベースのターゲットの復旧時間の変更 (SQL Server)」を参照してください。 |
| マニュアル | CHECKPOINT [ checkpoint_duration ] | Transact-SQL CHECKPOINT コマンドを実行すると発行されます。 接続している現在のデータベースで手動チェックポイントが作成されます。 既定では、手動のチェックポイントは最後まで実行されます。 調整は自動チェックポイントの場合と同様に行われます。 必要に応じて、 checkpoint_duration パラメーターを使用し、チェックポイントを完了するのに必要な時間を秒単位で指定します。 詳細については、「CHECKPOINT (Transact-SQL)」を参照してください。 |
| 内部 | [なし] : | ディスク イメージがログの現在の状態と一致することを保証するために、バックアップやデータベース スナップショット作成など、さまざまなサーバー操作によって発行されます。 |
Note
SQL Server の詳細設定オプションを使用すると、データベース管理者は -k、一部の種類のチェックポイントの I/O サブシステムのスループットに基づいてチェックポイント I/O 動作を調整できます。 -k 設定オプションは、自動チェックポイント、手動チェックポイント、および内部チェックポイントに適用されます (手動チェックポイントと内部チェックポイントは通常は調整されません)。
自動チェックポイント、手動チェックポイント、および内部チェックポイントでは、データベース復旧中にロールフォワードする必要があるのは、最新チェックポイントの後で行われた修正のみです。 これにより、データベースの復旧にかかる時間が短縮されます。
重要
実行時間の長い、コミットされていないトランザクションがあると、すべての種類のチェックポイントで復旧時間が長くなります。
TARGET_RECOVERY_TIME オプションと 'recovery interval' オプションの相互作用
次の表は、サーバー全体の sp_configure'recovery interval' 設定とデータベース固有の ALTER DATABASE ... の相互作用をまとめたものです。TARGET_RECOVERY_TIME設定。
| target_recovery_time | 'recovery interval' | 使用されるチェックポイントの種類 |
|---|---|---|
| 0 | 0 | ターゲット復旧間隔が 1 分の自動チェックポイント |
| 0 | >0 | ターゲット復旧間隔が sp_configurerecovery interval オプションのユーザー定義設定によって指定されている自動チェックポイント。 |
| >0 | 適用不可。 | 復旧時間が TARGET_RECOVERY_TIME 設定 (秒単位) によって設定されている間接チェックポイント ターゲット |
自動チェックポイント
自動チェックポイントは、サーバー構成オプションで指定された recovery interval 時間内にデータベース エンジンが処理できるログ レコードの数に達するたびに発生します。 ユーザー定義のターゲット復旧時間が設定されていないすべてのデータベースでは、データベース エンジンによって自動チェックポイントが生成されます。 自動チェックポイントの頻度は、高度なサーバー構成オプションによって recovery interval 異なります。これは、システムの再起動中に特定のサーバー インスタンスがデータベースの復旧に使用する最大時間を指定します。 データベース エンジンは、復旧間隔内に処理できるログ レコードの最大数を推定します。 自動チェックポイントを使用しているデータベースがこのログ レコードの最大数に達すると、データベース エンジンはデータベースにチェックポイントを発行します。 自動チェックポイントの作成間隔は大幅に変わります。 相当量のトランザクション ワークロードがあるデータベースでは、主に読み取り専用操作で使用されるデータベースよりもチェックポイントの作成回数が多くなります。
また、単純復旧モデルの場合、ログが全体の 70% に達すると自動チェックポイントもキューに登録されます。
単純復旧モデルでは、ログ トランザクションが何かの要因によって遅れていない限り、自動チェックポイントにより、トランザクション ログの未使用のセクションが切り捨てられます。 反対に、完全復旧モデルおよび一括ログ復旧モデルでは、ログ バックアップ チェーンが確立されると、自動チェックポイントによるログの切り捨ては行われなくなります。 詳細については、「トランザクション ログ (SQL Server)」を参照してください。
システム障害の後で所定のデータベースの復旧に必要な時間は、障害発生時点でのダーティ ページを再実行するために必要なランダム I/O の容量に大きく依存します。 これは、設定が recovery interval 信頼できないことを意味します。 正確な復旧間隔がわかりません。 さらに、自動チェックポイントの進行中に、データの一般的な I/O アクティビティが急に著しく増加します。
復旧のパフォーマンスに対する復旧間隔の影響
短いトランザクションを使用するオンライン トランザクション処理 (OLTP) システムの場合、 recovery interval 回復時間を決定する主な要因は です。 ただし、この recovery interval オプションは、実行時間の長いトランザクションを元に戻すために必要な時間には影響しません。 実行時間の長いトランザクションを含むデータベースの復旧には、 オプションで recovery interval 指定された よりもはるかに長い時間がかかる場合があります。 たとえば、サーバー インスタンスが無効になる前に実行時間の長いトランザクションが更新を実行するのに 2 時間かかった場合、実際の復旧には、長いトランザクションを復旧するための値よりも recovery interval かなり長い時間がかかります。 実行時間が長いトランザクションの復旧時間への影響の詳細については、「トランザクション ログ (SQL Server)」を参照してください。
通常は、既定値によって復旧の最適なパフォーマンスが得られます。 ただし、次のような状況では recovery interval を変更するとパフォーマンスが向上する可能性があります。
実行時間の長いトランザクションがロールバックされていないのに、復旧にかかる時間が常に 1 分を超える場合
チェックポイントの回数が多いためにデータベースのパフォーマンスが損なわれていると判断できる場合
recovery interval 設定を長くする場合には、少しずつ値を増やして、そのたびに復旧のパフォーマンスへの影響を評価することをお勧めします。 この方法は、設定が recovery interval 増えるにつれて、データベースの復旧が完了するまでに何倍も時間がかかるため、重要です。 たとえば、10 を変更 recovery interval した場合、復旧の所要時間は、 が 0 に設定されている場合 recovery interval よりも約 10 倍長くなります。
間接チェックポイント
SQL Server 2012 の新機能である間接チェックポイントは、自動チェックポイントに代わる構成可能なデータベース レベルを提供します。 間接チェックポイントでは、自動チェックポイントに比べて、システム障害時の復旧時間が短く、予測可能です。 間接チェックポイントには次の利点があります。
間接チェックポイントが構成されたデータベースでオンライン トランザクション ワークロードが生じると、パフォーマンスが低下することがあります。 間接チェックポイントは、ターゲットの復旧時間内でデータベースの回復が完了するように、ダーティ ページの数が特定のしきい値を下回るようにします。 復旧間隔構成オプションは、ダーティ ページ数を使用する間接チェックポイントとは異なり、トランザクション数を使用して復旧時間を決定します。 DML 操作の受信数が多いデータベースで間接チェックポイントが有効な場合、バックグラウンド ライターは積極的にディスクにダーティ バッファーのフラッシュを開始し、回復を実行するのに必要な時間をデータベースのターゲット復旧時間内にすることができます。 これにより、ディスクのサブシステムが I/O のしきい値よりも高い動作をするかまたはその値に近づいた場合、パフォーマンス ボトルネックの原因となる追加の I/O アクティビティが特定のシステムで発生する可能性があります。
間接チェックポイントを使用すると、REDO 時のランダム I/O のコストを計算に入れて、データベースの復旧時間を確実に制御できます。 このため、所定のデータベースで、復旧時にサーバー インスタンスが上限内にとどまることができます (実行時間の長いトランザクションによって過度の UNDO 回数が生じる場合以外)。
間接チェックポイントでは、ディスクへのダーティ ページの書き込みがバックグラウンドで続けられるため、チェックポイントに関連する I/O の急上昇が少なくなります。
ただし、間接チェックポイントが構成されたデータベースでオンライン トランザクション ワークロードが生じると、パフォーマンスが低下することがあります。 これは、間接チェックポイントで使用されるバックグラウンド ライターによって、サーバー インスタンスの合計書き込みロードが増える場合があるためです。
内部チェックポイント
内部チェックポイントは、ディスク イメージがログの現在の状態と一致することを保証するために、さまざまなサーバー コンポーネントによって生成されます。 内部チェックポイントは、次のイベントに応答して生成されます。
ALTER DATABASE を使用して、データベース ファイルが追加または削除された場合。
データベースのバックアップが作成された場合。
DBCC CHECK で明示的または内部的に、データベース スナップショットが作成された場合。
データベースのシャットダウンが必要な動作が実行された場合。 たとえば、AUTO_CLOSE が ON に設定されていて、データベースへの最後のユーザー接続が終了した場合、またはデータベースの再起動が必要なデータベース オプションが変更された場合です。
SQL Serverのインスタンスは、SQL Server (MSSQLSERVER) サービス を停止することによって停止されます。 どちらの場合でも、SQL Server のインスタンスの各データベースにチェックポイントが作成されます。
SQL Server フェールオーバー クラスター インスタンス (FCI) がオフラインになった場合。
Related Tasks
サーバー インスタンスで復旧間隔を変更するには
データベースで間接チェックポイントを構成するには
データベースで手動チェックポイントを発行するには
関連コンテンツ
- トランザクション ログの物理アーキテクチャ (SQL Server 2008 R2 Books Oline)