内部動作を知らずしてチューニングは語れない：真・Dr. K's SQL Serverチューニング研修（3）（2/3 ページ）

ラッチのチェックポイント

　大きく分けて、ラッチには3つの種類があります。

• PageIOLatch
• PageLatch
• Latch

　では、これらのラッチをそれぞれ解説しましょう。

PageIOLatch

　PageIOLatchは、ページバッファにデータが存在しないとき、ペ−ジバッファ上の更新済みページに対するチェックポイント処理時の、バッファフラッシュ処理時に発生するラッチです。

　アプリケーションはまず、ストレージエンジンにデータアクセスを行います。ストレージエンジンは、いきなりデータベースの物理ファイルにアクセスせず、中間にあるページバッファにデータが存在しないかを確認します。ページバッファにデータが存在しない場合、DB物理ファイルにI／Oが発生し、DB物理ファイルから、ページバッファにデータ転送が完了するまで待ちが発生します。それが、PageIOLatchです。当然、パフォーマンスにとって、PageIOLatchは発生しない方がいいわけですね。

図2　ページバッファへのI／OがPageIOLatchの発生源

　この図のように、ページバッファがキャッシュの働きをします。そのため、アプリケーションで必要なデータは、常にページバッファにあるようにしておけば、最大限のパフォーマンスを得られます。

　PageIOLatchが発生する原因は、メモリ上のページバッファの量が少ない、またDB物理ファイルのあるストレージのI／O 帯域が足りないなどが挙げられます。第2回で紹介した「バランスド・システム」にのっとって作られているかを確認しましょう。

　どのデータをページバッファ内に保持するかは、ストレージエンジンが判断します。更新済みページ（ダーティページ）は、チェックポイント処理によるバッファフラッシュが完了するまでは、必ずページバッファ内に保持されます。未更新のデータページは、メモリ上のページバッファ不足が発生すると、LRUアルゴリズムにより、バッファ内から破棄されます。

　未更新のデータページが、どれだけの時間ページバッファ内に保持されたかを確認するためには、SQL Serverパフォーマンスカウンターの、Buffer Manager : Page Life expectancyを参照します。単位は秒で、最低でもこの値は、300（5分間）以上が推奨値です。

PageLatch

　PageLatchは、ページ分割時に発生する待ちです。INSERT文によって、ページ内にあるデータがページの保持可能な上限数に達した場合、ストレージエンジンがページを2つに分割し、その中にあるデータが均等になるようにデータを移動します。このとき、インデックスもアップデートされます。この一連の作業を行うときに、データのI／Oが発生します。これがPageLatchです。

図3　PageLatchの発生場所

　図3を見てください。ページ1には「1」「4」「6」「8」という値を持つデータが入っています。1つのページには4つのデータしか入らない、という前提があるとしましょう。つまり、このページ1はもういっぱいの状態です。ここに「5」という値をINSERTしたとしましょう。

　すでにページ1はいっぱいの状態なので、ストレージエンジンはページ1ー1とページ1-2の2つに分割します。ページ1-1には「1」と「4」が、ページ1-2には「6」「8」が格納され、さらにインデックスが書き換えられます。このページ分割時にPageLatchが発生するわけです。

　これはクラスタ化インデックスカラムの選定を適切に行う、またインデックス作成時のfillfactor値が正しい設定で行われていれば問題はないはずです。つまり、PageLatchは初期の物理設計に起因する問題となりますので、必ず最初につぶしておきたいものです。