分類は照会中に頻繁に必要になるので、 分類ヒープ領域を正しく構成することは照会のパフォーマンス上きわめて重要になります。 次のような場合に、分類が必要になります。
分類には 2 つのステップが関係しています。
この 2 つのステップで分類が処理される方法はいくつかのカテゴリーまたはタイプに分けられるので、 以下ではそれを用いて分類の説明をします。 分類フェーズを考慮する際、 分類を"桁あふれ"と"桁あふれなし"に分けることができます。 分類フェーズの結果の戻りを考慮する際、 分類を"パイプ"と"非パイプ"に分けることができます。
分類される情報が分類ヒープ (分類の実行ごとに割り当てられるメモリーのブロック) に全く収まらない場合は、一時データベース表に桁あふれします。 桁あふれしない分類の方が常に、桁あふれする分類よりも効率良く実行されます。
データの最終分類結果リストを保管する一時表を使わなくても、 分類された情報を直接戻すことができる場合は、その分類は「パイプ分類」と呼ばれます。 分類された情報を戻すのに一時表が必要な場合には、 その分類は「非パイプ分類」と呼ばれます。 パイプ分類は、非パイプ分類よりも常に効率よく実行されます。
分類のパフォーマンスに影響を与える事柄には、以下のものがあります。
分類に関して総合的な問題があるかどうかを知るには、 分類に費やした合計 CPU 時間を、アプリケーション全体で費やした時間と比較してみてください。 比較には、データベース・システム・モニターが役立ちます (データベース・システム・モニターの使用法を参照してください)。 特に、「スナップショット・モニター」および「イベント・モニター」で構成され、 コントロール・センターから使用可能なパフォーマンス・モニターは、 省略時解釈では、合計分類時間 と共に 入出力時間 およびロック待機時間 などの時間を示します。
合計分類時間がその他の時間に占める比率が大きい場合には、 やはり省略時解釈で示される以下の値を調べてみてください。
一般に、インスタンス (sheapthres ) で使用可能な分類メモリーの全体量は、 過度のページングを引き起こさない限り、できるだけ大きくするようにしてください。 分類全体を分類メモリーで行うことができます。 ただし、その分類メモリーの増大に対応するために、 オペレーティング・システムが過度のページ・スワッピングを実行するようになった場合には、 大きな分類ヒープの利点がなくなる可能性があります。 そのため、分類構成パラメーターを調整するときには、 オペレーティング・システム・モニターを用いて、 システム・ページングに変更があるかどうかを突き止めてください。
注: | DB2 部分キーのバイナリー分類技法に、 非整数のデータ・タイプ・キーを組み込むように改善がなされたので、 長いキーを分類する時には追加のメモリーが必要です。 長いキーが使用されていると思う場合、 sortheap 構成パラメーターを増やしてください。 |
また、パイプ分類では、アプリケーションがその分類に関連したカーソルをクローズするまで、 分類ヒープが解放されないことに注意してください。 そのため、パイプ分類はカーソルがクローズされるまでメモリーを消費することができます。
データベース・システム・モニターとベンチマーク技法を使用すると、 構成パラメーター sortheap および sheapthres を設定するのに役立ちます。 データベース・マネージャーとそのデータベースごとに、次のことを実行してください。
これらのパフォーマンス変数は、 スナップショット・モニターのパフォーマンス詳細画面に示されます。
判別するのが困難である場合、最大の分類ヒープの 80% を使用します。
これは、初期設定としてお勧めします。 次に、ベンチマーク技法を使用して、この値をより良いものにすることができます。
さらに、分類が重大なパフォーマンス問題となっている特定のアプリケーションおよびステートメントを識別することができます。
注: | Explain 表を探索して、 どの照会で分類操作が行われているかを識別することができます。 (付録 H, SQL EXPLAIN ツールを参照してください。) |