バッファー・プール・アクティビティーのモニター

データベース・サーバーは、バッファー・プールのすべてのデータについて読み取りと更新を行います。アプリケーションの要求に応じて、データはディスクからバッファー・プールにコピーされます。

ページは、次のようにバッファー・プール内に置かれます。

エージェントによる。同期入出力です。
入出力サーバー (プリフェッチャー) による。非同期入出力です。

ページは、次のようにバッファー・プールからディスクに書き込まれます。

エージェントにより、同期で。
ページ・クリーナーにより、非同期で。

サーバーが 1 つのデータ・ページを読み取る必要があり、そのページがすでにバッファー・プール内にある場合は、ページをディスクから読み取るときよりも高速にそのページにアクセスできます。バッファー・プール内でできるだけたくさんのページをヒットすることが必要になります。ディスク I/O の回避はデータベースのパフォーマンスにおいて重要な要因であるため、バッファー・プールを適切に構成することが、パフォーマンスの調整について最も重要な考慮事項の 1 つになります。

バッファー・プールのヒット率は、データベース・マネージャーがページ要求を処理するときに、そのページがすでにバッファー・プール内に存在したためにディスクからページをロードする必要がなかった場合のパーセンテージを示します。バッファー・プール・ヒット率が高いほど、ディスク入出力の頻度は低くなります。

注: 以下の情報では、 Db2® pureScale® 環境以外の環境のバッファー・プールについて説明します。 Db2 pureScale 環境では、バッファー・プールの動作が異なります。詳しくは、 Db2 pureScale 環境でのバッファー・プールのモニターを参照してください。

例えば、全体のバッファー・プール・ヒット率は、次のように計算できます。

     ((pool_data_lbp_pages_found
+ pool_index_lbp_pages_found
 + pool_xda_lbp_pages_found
+ pool_col_lbp_pages_found
- pool_async_data_lbp_pages_found
- pool_async_index_lbp_pages_found - pool_async_xda_lbp_pages_found
- pool_async_col_lbp_pages_found) 
/ (pool_data_l_reads
+ pool_index_l_reads + pool_xda_l_reads + pool_col_l_reads + pool_temp_data_l_reads
+ pool_temp_xda_l_reads + pool_temp_index_l_reads + pool_temp_col_l_reads))
× 100

この計算には、バッファー・プールによってキャッシュされているすべてのページ (索引とデータ) が含まれます。

MON_BP_UTILIZATION 管理ビューを、バッファー・プールのヒット率をモニターする便利な方法として使用することもできます。

大規模なデータベースでは、バッファー・プールを大きくしても、バッファー・プール・ヒット率の効果が得られないことがあります。データ・ページ数が大きすぎるために、そのサイズを大きくしてもヒットの統計的な確率が高くならないことがあります。代わりに、索引のバッファー・プール・ヒット率を調整すると、よい結果を得られることがあります。これには 2 つの方法があります。

データと索引を 2 つの異なるバッファー・プールに分割し、それぞれを個別に調整します。
1 つのバッファー・プールを使用し、索引のヒット率がこれ以上高くならないというところまでそのバッファー・プールのサイズを大きくします。索引のバッファー・プール・ヒット率は、次のように計算できます。
```
((pool_index_lbp_pages_found
- pool_async_index_lbp_pages_found )  / (pool_index_l_reads
+ pool_temp_index_l_reads)) × 100
```

最初の方法のほうが効果が上がることが多いのですが、索引とデータを別の表スペースに置く必要があるので、既存データベースには利用できないことがあります。さらに、1 つではなく、2 つのバッファー・プールを調整する必要があるので、特にメモリーに制約があるときなどは困難な作業となります。

さらに、プリフェッチャーのヒット率に対する影響を考慮する必要があります。プリフェッチャーは、アプリケーションの必要性を予想して、データ・ページをバッファー・プール内に読み取ります (非同期)。多くの場合、これらのページは必要になる直前に読み込まれます (必要な場合)。ただし、プリフェッチャーは、使用されないページをバッファー・プール内に読み込むことで不要な入出力を行うこともあります。例えば、あるアプリケーションが表の読み取りを開始するとします。このことが検出されると、プリフェッチが開始しますが、アプリケーションはアプリケーション・バッファーを充てんして読み取りを停止します。この間に、その他の多数のページがプリフェッチされます。結局使用されることのないページについて入出力が行われ、バッファー・プールの一部がこうしたページで占められることになってしまいます。

ページ・クリーナーは、バッファー・プールをモニターし、ディスクにページを非同期で書き込みます。これには次の目的があります。

エージェントがバッファー・プール内でフリー・ページを必ず見つけられるようにする。エージェントがバッファー・プール内でフリー・ページを見つけられない場合は、エージェント自身がページをクリーニングしなければならないため、関連アプリケーションに対してよい応答を返せないことになります。
システムがクラッシュした場合に、データベースのリカバリーを迅速に行う。ディスクに書き込まれたページ数が多いほど、データベースのリカバリーで処理が必要となるログ・ファイル・レコードの数は少なくなります。

ダーティー・ページはディスクに書き出されますが、バッファー・プールに新しいページを読み取るためのスペースが必要な場合を除いて、このページはバッファー・プールからすぐには除去されません。

注: バッファー・プール情報は通常、表スペース・レベルで収集されますが、データベース・システム・モニターの機能は、この情報をバッファー・プールおよびデータベース・レベルまでロールアップすることができます。実行する分析の種類にもよりますが、いずれかのレベルまたはすべてのレベルでこのデータを調査する必要があります。