SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

Security Online Day 2024 春の陣

2024年3月13日(水)10:00~17:10

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

あたらしいSQL Server/Denaliの世界

Indirect Checkpoint (後編)

3. Indirect Checkpointの利用について

 これまでIndirect Checkpointについていろいろ説明してきましたが、Indirect Checkpointは実際どのような場合に使用すべきでしょうか。私は最初にIndirect Checkpointについて聞いたとき、使用するのには若干注意が必要かなと思いました。なぜなら、自動チェックポイントに比べて、Indirect Checkpointのほうがより頻繁にI/Oが発生する可能性を秘めているからです。具体的に言うと、これは短い間隔で同じページに対して頻繁に変更がかかるような環境の場合です。

 たとえば、UPADATE文が実行されてページ100番が変更されてダーティページになり、その1分後にまた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はデータベース単位で設定でき、従来と比べてより細やかにチェックポイントを制御できるようになります。是非、みなさんいろいろ試してみてください!

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
あたらしいSQL Server/Denaliの世界連載記事一覧

もっと読む

この記事の著者

古賀 啓一郎(コガ ケイイチロウ)

日本マイクロソフト株式会社勤務。きままなエンジニア。
謎があると解決せずにはいられない性格。
週末は家事に従事。 

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/3760 2012/02/15 00:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

2024年3月13日(水)10:00~17:10

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング