SHOEISHA iD

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

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

最新イベントはこちら!

EnterpriseZine Day 2024 Summer

2024年6月25日(火)オンライン開催

予期せぬ事態に備えよ! クラウドで実現するIT-BCP対策 powered by EnterpriseZine

2024年7月10日(水)オンライン開催

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

お申し込み受付中!

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

Indirect Checkpoint (前編)


こんにちは。日本マイクロソフトPremier Field Engineering部の古賀です。今回は、Indirect CheckpointというSQL Serverの新しいチェックポイントのしくみについて紹介します。

1. Indirect Checkpointとは

 Indirect Checkpointは、SQL Server 2012で新しく追加されるチェックポイントのしくみです。これまでSQL Serverは、チェックポイントのしくみとして「自動、手動、内部」を持っていましたが、これに加え、Indirect Checkpoint (間接) が追加されます。

 これまでのチェックポイントのしくみを簡単に説明すると、「自動」は、recovery interval サーバー構成オプションに指定された期限に合わせて、バックグラウンドで自動に発行されるチェックポイント、「手動」は、Transact-SQLのCHECKPOINTコマンドを実行することで発行されるチェックポイント、「内部」は、バックアップの採取時などさまざまな理由で内部的に発生するチェックポイントのことです。

 Indirect Checkpointは、これらのチェックポイントのしくみだけでは若干調整しづらかったデータベースの復旧時間や、チェックポイントによるI/O発行量をより細やかに調整できるように実装された機能です。

2. Indirect Checkpointが生まれた背景

  Indirect Checkpointが生まれた背景には、これまでのチェックポイントのしくみが抱えていてたいくつかの問題がありました。それは、以下のようなものです。

  •  復旧時間予測の問題
  •  I/Oスパイク
  •  復旧時における不必要なI/O
 復旧時間予測の問題

  SQL Serverはデータベースの復旧時間を、recovery intervalオプションで設定された時間内に収まるように、一定の間隔でチェックポイントを発行します。このチェックポイントを発行するタイミングは、基本的には前回のチェックポイントが発行されてから、どれほどのトランザクションログ レコードが生成されたかが元になっています。しかし、実際にはデータベースの復旧に要する時間を決定する要素は他にもいくつかあり (例えば、復旧処理のRedo処理で、どれほどのI/Oが発生するかといったこと)、recovery intervalオプションで設定した復旧時間は、若干ですが正確性に欠ける部分がありました。

 I/Oスパイク

  自動チェックポイントは、SQL ServerのI/Oアクティビティ (例えば、現在SQL ServerはどれほどディスクI/O待ちがあるのかといったこと) を考慮しながらチェックポイントを調整する仕組みを備えています。しかしながら、チェックポイントが始まると、予期していないほど急激にI/O負荷が増加することがありました。このような動作は、あらかじめシステムのI/Oアクティビティのピークがどれくらいなのかといったことを予測しづらくなります。

 復旧時における不必要なI/O

  チェックポイントの処理中、SQL Serverはトランザクションログ レコードの生成を無効にします。そのため、もし、チェックポイントの処理中にSQL Serverがクラッシュしてしまうと、チェックポイント中に書き込まれたページを特定するすべがありません。このようなチェックポイント中に発生したクラッシュからの復旧処理では、すでにチェックポイント処理で書き込まれていたページもRedo処理にて読み込む必要が発生し、不必要なI/Oが行われます。

  Indirect Checkpointは、このような問題を改善するために実装されました。とくに、上述の「復旧時間予測の問題」の改善に最も焦点をあてて実装されています。

次のページ
3. データベースの復旧時間

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

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

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/3750 2012/02/10 18:33

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング