4. Indirect Checkpointのしくみ
では、このようなSQL Serverのデータベース復旧のしくみとチェックポイントの関係を踏まえて、Indirect Checkpointはどのように機能するのでしょうか？実は、SQL Server 2012では、新たにBackground Writerと呼ばれるIndirect Checkpoint用のシステム スレッドが常駐しており、このスレッドが通常の自動チェックポイントとはまったく別のタイミングで、ユーザーによって設定された復旧時間を達成するよう定期的にダーティページ (ディスクの内容と異なっているメモリ上のページ) をディスクへフラッシュしてくれるようになるのです。
これまでは自動チェックポイントが発生してから、次の自動チェックポイントが発生するまでの間は、手動でチェックポイントを発行しない限り、ダーティページ、つまり、復旧時におけるRedoページが増える一方でしたが、Indirect Checkpointを構成すると、自動チェックポイントが発生してから次の自動チェックポイントが発生するまでの間も、Background Writerが目標の復旧時間を達成するために、定期的にダーティページをフラッシュしてくれるようになるのです。Background Writerがダーティページをフラッシュするかどうかの判断には、自動チェックポイントとは異なりRedo時のI/O負荷も考慮されています。
お気づきの方もいらっしゃるかもしれませんが、前述の通り復旧時間はRedoの処理量に加えて、Undoの処理量にも依存します。しかし、これはクラッシュ時のユーザーのトランザクションの長さに大きく依存する部分であり、Indirect Checkpointはこの点について関与できません。
***
今回は、Indirect Checkpointの生まれた背景やそのしくみについて紹介しました。次回の記事では、Indirect Checkpointの設定方法や使用上の注意点について紹介したいと思います。お楽しみに！
