スナップショット・モニタに基づくチューニング：DB2チューニング・ベストプラクティス（5）（3/4 ページ）

[Fraser McArthur，DB2 Enablement Consultant／IBM Canada Ltd.]

SHEAPTHRES_SHR（DBM）

　このパラメータは、同時に実行される共有ソートがインスタンス内で使用できるメモリの合計量に関するハード制限を表します。これが適用されるのは、

1. INTRA_PARALLEL=YESの場合
2. 接続コンセントレータがON
   （MAX_CONNECTIONS ＞ MAX_COORDAGENTS）の場合

のいずれかです。WITH HOLDオプションを伴うカーソルを使用するソートは、共有メモリから割り振られます。

　「Shared Sort heap high water mark」は、一度に割り振られた最大の共有ソート・メモリを表します。この値がSHEAPTHRES_SHRより大幅に低い場合は、データベースのほかの機能にメモリを残しておくために、SHEAPTHRES_SHRの値を減らします。逆に、この値がSHEAPTHRES_SHRに非常に近い場合は、SHEAPTHRES_SHRの値を増やします。「Total Shared Sort heap allocated」（割り振られた共有ソート・ヒープの合計）は、すべてのソートのためのソート・ヒープ・スペースの割り振り済みページの総数です。この値がSHEAPTHRES_SHRと同じか、それより大きい場合は、SORTHEAPパラメータによって定義されたソート・ヒープがソート時にフルに利用されていないことを表します。これを解決するには、SHEAPTHRES_SHRのサイズを増やします。

　このパラメータの値は、SORTHEAPの倍数になるように設定します。

SORTHEAP（DB）

　このパラメータは、専用ソートで使用する専用メモリ・ページの最大数、または共有ソートで使用する共有メモリ・ページの最大数を定義します。それぞれのソートは、独立したソート・ヒープを持ちます。これらは、必要に応じてデータベース・マネージャによって割り振られます。

　ソートに必要なメモリの量がSORTHEAPの値を超えると、ソート・オーバーフローが発生します。このことはよく知られていますが、このほかにも統計情報が古い場合や、データに偏りがあるのに分散統計を収集していない場合にもオーバーフローが発生することは、あまり知られていません。これらの場合、DB2によって要求されるソート・ヒープが非常に小さく、要求された量を実際のソート操作が上回ると、オーバーフローが発生します。従って、統計を常に最新のものに保つことが重要です。また、適切な索引が存在しない結果としてソートが行われないように注意する必要があります。

　OLTPの場合は「128」、OLAPの場合は「4096」〜「8192」から始めるとよいでしょう。「Sort overflows」（ソート・オーバーフロー）の数が多い（2けた）場合は、おそらくSORTHEAPを増やす必要があるでしょう。「Number of hash join overflows」（ハッシュ結合のオーバーフローの数）が「0」でない場合は、「0」になるまでSORTHEAPを「256」ずつ増やします。「Number of small hash join overflows」（ハッシュ結合の短精度オーバーフローの数）が「0」でない場合は、「0」になるまでSORTHEAPを10％ずつ増やします。

CHNGPGS_THRESH（DB）

　このパラメータは、バッファ・プール内の変更済みページの割合（パーセンテージ）を指定するために使います。変更済みページの割合がこの値に達すると、非同期ページ・クリーナが起動され、変更がディスクに書き込まれます。これは、新しいデータのためのスペースをバッファ・プール内に確保するためです。読み取り専用環境では、ページ・クリーナは使用されません。OLTPでは、値を「20」〜「40」にするとパフォーマンスが向上します（更新処理を大量に行う場合は「20」に設定します）。その理由は、この値を低くすることにより、非同期ページ・クリーナがダーティーなバッファ・プール・ページをより頻繁に書き出すようになるからです（各回の処理時間は逆に短くなります）。INSERTやUPDATEの数が多くない場合は、OLTPでもOLAPでも、デフォルト値の「60」のままでよいでしょう

　「Dirty page steal cleaner triggers」（ダーティー・ページ・スチール・クリーナの起動数）の値が2けたである場合は、このパラメータの値を低くします。「Buffer pool data writes」（バッファ・プールのデータ書き込み回数）の値が高く、「Asynchronous pool data page writes」（バッファ・プールの非同期データ書き込み回数）の値が低い場合も、このパラメータの値を低くしてください。

　FixPak 4では、特定のバッファ・プールのパフォーマンスを向上させることのできる、新しいページ・クリーニング・アルゴリズムを利用できます。これを利用するには、プロファイル・レジストリ変数「DB2_USE_ALTERNATE_PAGE_CLEANING=YES」を設定します。この場合、CHNGPGS_THRESHの設定は無視されます。NUM_IOSERVERSの値が「3」以上であることを確認してください。そうでないと、この新しいアルゴリズムは適切に動作しません。

NUM_IOCLEANERS（DB）

　このパラメータは、データベースの非同期ページ・クリーナの数を定義します。非同期ページ・クリーナは、変更されたページをバッファ・プールからディスクに書き込みます。最初はこのパラメータの値を、システムのCPU数と同じに設定するとよいでしょう。非同期ページ・クリーナが起動される場合、それらはすべて同時に起動されるため、あまり数を多くし過ぎるとパフォーマンスが低下し、ほかの処理をブロックしてしまいます。

　AWP（Asynchronous Write Percentage：非同期書き込みパーセンテージ）が90％以上である場合は、NUM_IOCLEANERSを減らしてください。逆に、90％未満の場合は増やしてください。

AWP = (("Asynchronous pool data page writes" +          "Asynchronous pool index page writes") * 100) /  ("Buffer pool data writes" + "Buffer pool index writes")

NUM_IOSERVERS（DB）

　入出力サーバは、プリフェッチを実行するために使用されます。このパラメータは、データベースの入出力サーバの最大数を定義します。非プリフェッチ入出力はデータベース・エージェントから直接スケジューリングされるため、このパラメータには制約されません。最初はこのパラメータの値を、「データベースが存在している物理ディスクの数（ディスク・アレイ内や論理ボリューム内に多くのディスクが含まれる場合も同じです）＋1または2」に設定します。ただし、CPUの数の4〜6倍を超えないようにしてください。CPUの数の4〜6倍を超えさえしなければ、値を大きくしてもパフォーマンスが低下することはありません。

「Time waited for prefetch (ms)」（プリフェッチ待ち時間）の値が秒単位で示される場合は、入出力サーバを追加して、パフォーマンスが向上するかどうかを確認します。

MAXFILOP（DB）

　このパラメータは、各データベース・エージェントに対してオープンできるファイルの最大数を定義します。この値より多くのファイルをオープンすると、エージェントによって使用中のファイルがいくつかクローズされます。ファイルのオープンとクローズが多過ぎると、パフォーマンスが低下します。SMS（システム管理スペース）表スペースとDMS（データベース管理スペース）表スペース・ファイル・コンテナは、どちらもファイルとして扱われます。一般的に、SMSの方が多くのファイルを使用します。

　「Database files closed」（クローズされたデータベース・ファイル）の値が「0」になるまで、この値を増やします。（次ページに続く）