|このフィーチャーは、Sun Solaris 操作環境でのみサポートされています。
|入出力のオーバーヘッドのために、ページをディスクからプリフェッチすることは、 |費用のかかる操作です。DB2 のプリフェッチは、処理を入出力とオーバーラップできる場合に、 |スループットを大幅に改善します。大半のプラットフォームは、 |連続するページをディスクから不連続なメモリーの部分に読み取るための高性能なプリミティブを |備えています。これらのプリミティブは通常、"分散読み取り"または"ベクトル I/O"と呼ばれます。プラットフォームによっては、これらのプリミティブのパフォーマンスは、 |大きなブロック・サイズでの入出力とは比較にならない場合があります。 |デフォルトでは、バッファー・プールは、ページ・ベースです。つまり、ディスク上の連続するページは、メモリー内の |不連続のページにプリフェッチされます。ページをディスクからバッファー・プールの連続する |ページに読み取ることができれば、プリフェッチのパフォーマンスは、これらのプラットフォーム上で |さらに改善します。レジストリー変数 DB2_BLOCK_BASED_BP を使用すれば、 |一連の連続するページを保持するバッファー・プールにセクションを作成できます。 |これらの一連の連続するページは、"ブロック"と呼ばれます。このレジストリー変数を |設定すれば、順次プリフェッチは、各ページを個別に読み込むのではなく、 |ページをディスクから直接、これらのブロックに読み込みます。これによって入出力のパフォーマンス |が改善されます。このレジストリー変数について詳しくは 管理の手引き の「レジストリーおよび環境変数」 |のセクションを参照してください。 |
|エクステント・サイズの異なる複数の表スペースをブロック・サイズが同じバッファー・プールに |結合することができます。エクステント・サイズとブロック・サイズは、別個の概念を扱うにも |かかわらず、両者の間には密接な関係があります。 エクステントとは、表スペースが複数のコンテナー |にわたってストライプされる細分度です。 |ブロックとは、順次プリフェッチ要求を実行する入出力サーバーが、ブロック・ベースの入出力 |の実行を考慮する唯一の細分度です。
|個々の順次プリフェッチ要求は、エクステント・サイズ・ページを使用します。そのような |プリフェッチ要求を受け取ると、入出力サーバーは、各要求を分散読み取り方式を用いたページ・ |ベースの入出力ではなく、ブロック・ベースの入出力として実行する場合のコストおよび利点を判別 |します (バッファー・プールにブロック・ベースの領域がある場合)。 |あらゆる入出力をブロック・ベースの入出力として実行する利点は、 |連続するディスクから連続するメモリーに読み込む |ことによるパフォーマンス上の利点にあります。 |コストは、この方式の使用により無駄になる |バッファー・プール・メモリーの量です。
|ブロック・ベースの入出力を実行する場合は、次の 2 つの理由により、 |バッファー・プール・メモリーが無駄になる可能性があります。 |
|入出力サーバーは、ブロック・ベースの入出力を実行する利点を得るために、各ブロック内に多少の |無駄なページを見越しています。しかし、あまりに多くのブロックが無駄になる場合は、 |入出力サーバーは、バッファー・プールのページ域にページ・ベースでプリフェッチする方式に |戻ります。その結果、プリフェッチ中に行われた入出力の一部は、 |ブロック・ベースではありません。これは最適な状態ではありません。
|最適なパフォーマンスのためには、エクステント・サイズが同じ表スペースを |ブロック・サイズが同じバッファー・プールに結合する必要があります。良いパフォーマンスは、 |一部の表スペースのエクステント・サイズが結合先のバッファー・プールのブロック・サイズより大き |い場合でも、達成できます。エクステント・サイズがブロック・サイズより小さい場合は、 |表スペースのバインドはお勧めしません。
|AWE とブロック・ベースのサポートの両方を同時にバッファー・プールのセットアップとすることは |できません。DB2_AWE および DB2_BLOCK_BASED_BP レジストリー変数の両方が同じバッファー・プールを |参照する場合は、AWE に優先順位が与えられます。ブロック・ベースのサポートは、この場合、 |使用不可になり、AWE が使用不可になった場合にのみ再び使用できるようになります。
|拡張記憶域を使用するバッファー・プールは、ブロック・ベースの入出力を |サポートしていません。 |
|例を検討する前に、システム上のバッファー・プールの ID について知る必要があります。 |バッファー・プールの ID は、BUFFERPOOLID 列または SYSCAT.BUFFERPOOLS システム・カタログ視点を調べれば |わかります。
|シナリオ 1
|ページ数が 1000 ページであり ID が 4 のバッファー・プールがあります。各ブロックに 32 ページ |が含まれ、700 ページからなるブロック域を作成するとします。次のコマンドを実行する必要があります。
| db2set DB2_BLOCK_BASED_BP=4,700,32
|データベースが始動すると、ID が 4 で、ブロック域が 672 ページ、ページ域が 328 ページの |バッファー・プールが作成されます。この例では、32 を均等に 700 に分割 |することはできません。つまり指定されたブロック域サイズは、 |次の公式を用いて最も近いブロック・サイズ境界に削減される必要があります。
| ((block area size)) | FLOOR(-----------------) X block size | ( (block size) ) | ( 700 ) | = FLOOR(-----------------) X 32 | ( 32 ) | = 21 x 32 | = 672
|シナリオ 2
|ページが 3000 ページであり ID が 11 のバッファー・プールがあります。 |2700 ページからなる |ブロック域を作成するとします。 |次のコマンドを実行する必要があります。
| db2set DB2_BLOCK_BASED_BP=11,2700
|データベースが始動すると、ID が 11 で、ブロック域が 2688 ページ、ページ域が 312 ページの |バッファー・プールが作成されます。 |ブロック・サイズに明確な値を指定しないと、 |デフォルト値 32 が使用されます。この例では、32 を均等に 2700 に分割 |することはできません。 |つまり指定されたブロック域サイズは、 |次の公式を用いて最も近いブロック・サイズ境界に削減される必要があります。
| ((block area size)) | FLOOR(-----------------) X block size | ( (block size) ) | ( 2700 ) | = FLOOR(-----------------) X 32 | ( 32 ) | = 84 x 32 | = 2688