I/Oチューニングを成功させる必修ポイント：Dr. K's SQL Serverチューニング研修（6）（2/3 ページ）
専用パーティションを用意して、ディスクI/Oの負荷分散を図る
トランザクションとページバッファのやりとりは「論理I/O」（Logical write／Logical read）と呼ばれますが、これはアプリケーションとSQL Serverのキャッシュの間のやりとりですから、いくらI/Oが多くてもメモリ上に必要なデータがあるかぎり問題はありません（メモリ不足による問題については第2回、第3回を参照）。バッファマネージャは、バッファキャッシュ上の空領域が不足すると、LRUと呼ばれるアルゴリズムにより、未更新で、最も古くからキャッシュ上に存在するページ上に、新たに読み込んだページを上書きします。
問題なのは、物理I/Oです。アプリケーションからのI/O要求頻度が高くなり、バッファキャッシュ上に必要なデータがない場合、広範囲なデータ参照によるテーブルスキャンなどの処理が発生すると、物理ディスクからバッファキャッシュへの読み込みが必要になり、I/O待ち行列が発生します。この待ち行列の長さを「Disk Queue Length」といいます。この値（ディスクアクセスを待っているシステム要求数）はWindows OSのシステムモニタから「Physical Disk: Current Disk Queue Length」カウンタで確認できます。I/Oチューニングで一番大事なのは、このI/Oのディスク書き込みの待ち行列の発生を、いかに抑制するかという点です。図2と図3に、私が過去に扱った事例で、チューニング前の物理I/Oの状態（パフォーマンス監視ツールの画面）をお見せします。
SQL Serverとファイルシステムという観点から注目しなくてはならないのは、「ログファイルは順アクセスである」という点です。トランザクションログファイルの役目はリカバリ用のデータを時系列的に保存していくことですから、これは当然といえるでしょう。これに対して、通常のデータ領域が収められている「MDF」や「NDF」といったファイルはランダムアクセスです。ファイルアクセスの観点で性質の相反するファイルを同じディスクに置くと、ディスクヘッドの競合という問題が発生します。
I/Oチューニングの第一歩として、アクセス方法が違うものを分割する単位が、ドライブレター（ストレージのパーティション）であるということを理解してください。例えば、ドライブレターの「D」をトランザクションログファイル専用のパーティションにするとしましょう。SQL Serverは1つのインスタンスの中に複数のデータベースを持つことができる（ここがOracleと大きく異なる点です）ので、複数のデータベースを作成したら、それらのトランザクションログファイルをすべて、専用のパーティション「D」に集めることがパフォーマンス向上に有効です。
SQL ServerのI/Oチューニングでは、トランザクションログ専用のパーティションのほかに、3種類の専用パーティションを用意することを推奨しています。
まずは「tempdb」専用パーティションです。tempdbとはSQL Serverが持っている特殊なシステムデータベースです。これは、複数のテーブルを結合するための中間の結果セットを保存したり、「order by」のように結果を並べ替える、あるいは「group by」でアグリゲーションを行って集計値を返す、といったクエリ要求が来たときに使用されます。tempdbはSQLの書き方によっては非常に負荷が高くなります。そうなるとこのtempdbにも、専用のパーティションを与えた方がいいわけです。
そして残りの2つは、通常はユーザー用のデータベースのデータ領域に充てられます。1つには、テーブルとクラスタ化インデックスのインデックス情報とクラスタ化インデックスの「ヒープ」と呼ばれる最下位の部分を入れます。
そして重要なのは、もう1つの非クラスタ化インデックス用のパーティションです。SQL Server 2000は、1つのテーブルに対して非クラスタ化インデックスを249個まで作成できます。この非クラスタ化インデックスがINSERT／UPDATEの多発するテーブルに複数定義されている場合は、別のパーティションに格納した方が、効率が良い場合があります。というのも、SQL ServerはOSに対してパーティションの数だけI/Oの依頼を並行して出せるので、データの更新処理と、インデックス情報の更新でI/O負荷分散が可能です。（次ページへ続く）
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。