3. Indirect Checkpointの利用について
これまでIndirect Checkpointについていろいろ説明してきましたが、Indirect Checkpointは実際どのような場合に使用すべきでしょうか。私は最初にIndirect Checkpointについて聞いたとき、使用するのには若干注意が必要かなと思いました。なぜなら、自動チェックポイントに比べて、Indirect Checkpointのほうがより頻繁にI/Oが発生する可能性を秘めているからです。具体的に言うと、これは短い間隔で同じページに対して頻繁に変更がかかるような環境の場合です。
たとえば、UPADATE文が実行されてページ100番が変更されてダーティページになり、その１分後にまたUPADATE文が実行されて同じページ100番が変更されるような環境です。このような場合、フラッシュ間隔が短く設定されている環境のほうが、フラッシュ間隔長い環境に比べてI/O回数が多くなることがあります。なぜなら、フラッシュ間隔が短いと最初のページ変更の後、2回目のUPDATE文が実行される前にページの内容をフラッシュしてしまう可能性が高くなるからです。フラッシュ間隔が長い場合は、短い場合と比較して2回目のUPDATE文でメモリ上のページが書き換わってから、ページをフラッシュできる可能性がより高くなります。つまり、2回のメモリの変更に対して、2回のフラッシュが必要となるのか、1回のフラッシュで済んでしまうのかということです。
このようなBackground WriterのI/O量の増加現象は、データベース ミラーリングのミラー側 (SQL Server 2012でいえば、Availability Groupのセカンダリ) で発生するI/O量増加現象に似ています。データベース ミラーリング構成では、ミラーリング フェールオーバーのスピードを速めるため、つまり、復旧処理のRedo処理の時間を短くするために、ミラー側では頻繁にデータファイルへのI/O処理が実行されています。データベース ミラーリングをご利用いただいている方はご存知かもしれませんが、一般的にミラー側のデータファイルへのI/O量は、プリンシパル側のI/O量より多くなり、どうしても負荷が高まってしまう傾向があります。
そのため、ワークロードによってはミラー側と似たような動作をするIndirect Checkpointを利用すると、パフォーマンスに影響が出るかもしれません。結局のところ、Indirect Checkpointを利用するかどうかは、基本的には前回紹介したこれまでのチェックポイントが抱えている問題点に合致して、何とかしたい場合といえるでしょう。例えば、復旧時間についてrecovery intervalオプションで設定した以上の正確性を求める場合や、I/Oスパイクの問題に悩まされているような場合です。そのような場合は、Indirect Checkpointを利用すべきですが、使用の際にはパフォーマンスに影響が無いか確認が必要だということです。
最後に、前述した内容とは別の観点で、私がIndirect Checkpointを有効活用できるかもしれないなと思っている点を挙げると、Indirect Checkpointがデータベース単位で設定できるという点です。データベース単位で設定できるということは、チェックポイントの動作をより決め細やかに調整することが可能になります。例えば、1つのSQL Serverインスタンスに複数のデータベースが存在していて、復旧時間が長くてもかまわないようなデータベースが存在している場合は、復旧時間を長めに設定しておくことができるので、逆にサーバー全体のI/O負荷を軽減できるかもしれません。
***
いかがだったでしょうか？
SQL Server 2012では、Indirect Checkpointの機能が追加されることで、従来抱えていたチェックポイントの問題点が改善されることを説明しました。しかし、その使用には注意が必要な点があることも説明しました。既定では有効になっていない機能ですが、ALTER DATABASEを実行するだけで簡単に設定できます。これまでのチェックポイントのしくみに困っていなくても、Indirect Checkpointはデータベース単位で設定でき、従来と比べてより細やかにチェックポイントを制御できるようになります。是非、みなさんいろいろ試してみてください！
