管理の手引き


キャパシティー管理

データベースとデータベース・マネージャーの両方のレベルで、 システムのスループットを制御する構成パラメーターがいくつかあります。 この種のパラメーターは、次のカテゴリーに分けることができます。

DB2 メモリー管理の紹介については、DB2 でのメモリーの使用方法を参照してください。

データベース共用メモリー

次のパラメーターは、システムで割り振られるデータベース大域メモリーを制御します。

データベース大域メモリーと、 データベース・マネージャーで割り振られるそれ以外のメモリーとの関係については、 DB2 でのメモリーの使用方法を参照してください。

バッファー・プール・サイズ (buffpage)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX 32 ビット・プラットフォーム
1 000 [ 2 〜 524 288 ]

UNIX 64 ビット・プラットフォーム
1 000 [ 2 〜 2 147 483 647 ]

OS/2 および Windows NT
250 [ 2 〜 524 288 ]

計測単位
ページ

割り振りタイミング
最初のアプリケーションがデータベースに接続したとき

解放タイミング
最後のアプリケーションがデータベースから切断したとき

関連パラメーター

各データベースは、少なくとも 1 つのバッファー・プール (IBMDEFAULTBP、 これはデータベースの作成時に作成される) を持ちますが、 さらに多くのバッファー・プールを持つこともできます。 すべてのバッファー・プールは大域メモリーに常駐し、 このデータベースを使用するすべてのアプリケーションが利用できます。 メモリーは、そのデータベースがあるマシンで割り振られます。 バッファー・プールが十分に大きくて、 メモリー内の必要なデータをすべて保持できる場合は、 ディスク・アクティビティーはより少なくて済みます。 逆に、バッファー・プールが十分大きくないと、 データベース全体のパフォーマンスは著しく低下することがあり、 アプリケーションで必要なデータを処理するためのディスク・アクティビティー (入出力) が増えるためにデータベース・マネージャーが入出力制約を受けることがあります。

buffpage パラメーターは、CREATE BUFFERPOOL または ALTER BUFFERPOOL ステートメントが NPAGES -1 を指定して実行されるときに、 バッファー・プールのサイズを制御します。 それ以外の場合は、buffpage パラメーターは無視され、 バッファー・プールは NPAGES パラメーターの指定するページ数だけ作成されます。

バッファー・プールに buffpage パラメーターが活動中になっているかどうかを判別するには以下のようにしてください。

  SELECT * from SYSCAT.BUFFERPOOLS.

NPAGES 値が -1 である各バッファー・プールは buffpage を使用します。

バッファー・プール・サイズと他のシステム・ユーザーのメモリー割り振りとの間には、 トレードオフがあります。 トランザクション率が高い複数ユーザーのサーバーではデータベース・サーバーのメモリー所要量が大きな意味を持つので、 データベース・サーバーとファイル / 通信サーバーを別々のマシンに置くことがよくあります。

照会でニックネームにアクセスする場合、次のようなときには、 バッファー・プール・サイズの増加を考慮に入れてください。

バッファー・プールは、最初のアプリケーションがデータベースに接続したとき、 またはデータベースが明示的に活動化されたときに、すべて割り振られます。 アプリケーションがデータベースにデータを要求すると、 そのデータが含まれているページがディスクからバッファー・プールに転送されます。 (ディスク上の表では、 データベース・データはページ単位で保管されていることに注意してください。) ページが変更され、次のことが起こった場合に限り、 転送されたページがディスクに戻されます。

推奨事項:

データベース・システム・モニターを使用して、バッファー・プールのヒット率を計算し、 バッファー・プールの調整を行うことができます。 システム・モニター 手引きおよび解説書 を参照してください。

データベース・ヒープ (dbheap)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
1200 [ 32 〜 524 288 ]

OS/2 および Windows NTローカル・クライアントおよびリモート・クライアントをもつデータベース・サーバー
600 [ 32 〜 524 288 ]

OS/2 および Windows NTローカル・クライアントをもつデータベース・サーバー
300 [ 32 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
データベースに最初に接続したとき

解放タイミング
最後のアプリケーションがデータベースから切断したとき

関連パラメーター

データベースごとに 1 つのデータベース・ヒープがあります。 データベース・マネージャーは、データベースに接続するすべてのアプリケーションのためにそのデータベース・ヒープを使用します。 これには、表、索引、表スペース、およびバッファー・プールの制御ブロック情報が入っています。 また、ログ・バッファー (logbufsz)、 およびカタログ・キャッシュ (catalogcache_sz) も入っています。 したがって、ヒープのサイズは、 ある時点でヒープに保管されている制御ブロックの数によって異なります。 制御ブロック情報は、 すべてのアプリケーションがデータベースから切断するまでヒープに保持されます。

最初に接続した時点で、データベース・マネージャーを開始するのに必要な最低限の量が割り振られます。 必要に応じてデータ域は拡張していき、 dbheap で指定された最大量に達するまで拡張します。

推奨事項: データベース・ヒープの記憶域が足りないため、 ステートメントを処理できないことを示すエラーがアプリケーションに戻ったときは、 この値を増す必要があります。

データベース・ヒープで使用されたメモリーの最大量をトラックするには、 データベース・システム・モニターを使用することができます。 詳しくは、システム・モニター 手引きおよび解説書 の中の db_heap_top (割り振られるデータベース・ヒープの最大値) モニター要素の説明を参照してください。

このパラメーターを設定するときは、 以下の点を考慮する必要があります。

カタログ・キャッシュ・サイズ (catalogcache_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
64 [ 1 〜 60 000 ]

OS/2 および Windows NTローカル・クライアントおよびリモート・クライアントをもつデータベース・サーバー
32 [ 1 〜 60 000 ]

OS/2 および Windows NTローカル・クライアントをもつデータベース・サーバー
16 [ 1 〜 60 000 ]

計測単位
ページ (4 KB)

関連パラメーター

このパラメーターは、 データベース・ヒープ (dbheap ) からカタログ・キャッシュが使用できるスペースの最大量を示します。 カタログ・キャッシュは、SQL ステートメントのコンパイルで表、視点、 または別名を参照するときに使用する表記述子情報を保管するためのものです。

このキャッシュを使用すると、 以前のステートメントで参照したのと同じ表、 視点または別名を参照する場合、 SQL ステートメント (動的 SQL を含む) を結び付けるパフォーマンスが向上します。 宣言済み一時表の記述子情報は、 カタログ・キャッシュに保管されず、代わりにアプリケーション制御ヒープが使用されます。

ある表に対して DDL ステートメントを実行した場合、 カタログ・キャッシュ内のその表の項目は除去されます。 それ以外の場合は、他の表がそのスペースを必要とするまで表項目はキャッシュ内に保持されます。 なお、その表を参照していた作業単位が完了するまで、 表項目がキャッシュから除去されることはありません。

推奨事項: 最初は省略時値で開始し、 次にそれをデータベース・システム・モニターを使って調整してください。

以下のモニター要素については、 システム・モニター 手引きおよび解説書 を参照してください。

これらのデータベース・システム・モニター要素を用いると、 この構成パラメーターを調整する必要があるかどうかを判別することができます。 このパラメーターを調整するときは、 少しずつ (たとえば、一度に 2 ページ) 大きくしていってください。
注:カタログ・キャッシュは、 マルチノード環境のカタログ・ノードにだけ作成されます。

一般的に、動的 SQL ステートメントを複数含んでいる作業単位の場合、 または静的 SQL ステートメントを多数含んでいるパッケージをバインドしている場合は、 より大きなキャッシュ・スペースが必要になります。

カタログ・キャッシュのサイズを設定するときは、ログ・ファイルのサイズ (logbufsz ) についても考慮してください。 catalogcache_szlogbufsz は、 どちらもデータベース・ヒープ (dbheap ) から割り振られるからです。

ログ・バッファー・サイズ (logbufsz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX 32 ビット・プラットフォーム
8 [ 4 〜 4 096 ]

UNIX 64 ビット・プラットフォーム
8 [ 4 〜 65 535 ]

OS/2 および Windows NT
8 [ 4 〜 4 096 ]

計測単位
ページ (4 KB)

関連パラメーター

このパラメーターは、 ログ・レコードをディスクに書き込む前にバッファーとして使用するデータベース・ヒープ (dbheap パラメーターで定義する) の大きさを指定します。 これらのログ・レコードは、以下のことが発生した場合にディスクに書き込まれます。

さらに、 このパラメーターは dbheap パラメーターと同じかそれより小さくなっている必要があります。 ログ・レコードのバッファリング機能によって、 ディスクに書き込む頻度が少なくなり、 一度に書き込まれるログ・レコードの数が多くなるので、 ログ・ファイルのファイル入出力がさらに効率的になります。

推奨事項: 専用ログ・ディスクにおける読み取りアクティビティーがかなり活発である場合、 またはディスク使用率が高い場合は、このバッファー域のサイズを増してください。 専用ログ・ディスクの読み取りアクティビティーが非常に多い場合、 またはディスク使用率が高い場合は、このバッファー域のサイズを大きくしてください。 ログ・バッファー域は dbheap パラメーターで制御されているスペースを使用するので、 このパラメーターの値を大きくする場合は、dbheap パラメーターの設定も検討してください。

特定のトランザクション (または作業単位) にどれだけのログ・バッファー域が使用されているかは、 データベース・システム・モニターを使って判断することができます。

詳細については、 システム・モニター 手引きおよび解説書 の中の log_space_used (使用中の作業単位ログ・スペース) モニター要素の説明を参照してください。

ログ・バッファー・サイズを設定するときは、 カタログ・キャッシュ・サイズ (catalogcache_sz) についても考慮してください。 logbufsz_szcatalogcache_sz は、 どちらもデータベース・ヒープ (dbheap) から割り振られるからです。

ユーティリティー・ヒープ・サイズ (util_heap_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
5000 [ 16 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
データベース・マネージャー・ユーティリティーで必要が生じたとき

解放タイミング
ユーティリティーでメモリーが必要なくなったとき

関連パラメーター

このパラメーターは、BACKUP、RESTORE、 LOAD およびロード回復ユーティリティーが同時に使用できるメモリーの最大量を示します。

推奨事項: ユーティリティーにスペース不足が起きない限り、 省略時値を使用してください。 不足になったら、値を増します。 システムのメモリーに制限がある場合は、このパラメーターの値を小さくし、 データベース・ユーティリティーで使用されるメモリーを制限することができます。 ただし、パラメーターの設定が低すぎると、 ユーティリティーを並行して実行できないことがあります。 並行ユーティリティーのために割り振りたいバッファーをすべて保持できるよう、 十分な大きさを設定してください。

省略時のバックアップ・バッファー・サイズ (backbufsz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
1024 [ 8 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
バックアップ・ユーティリティーが呼び出されたとき

解放タイミング
バックアップ・ユーティリティーが処理を完了したとき

関連パラメーター

このパラメーターは、 バックアップ・ユーティリティーを呼び出した時点でバッファー・サイズが明示指定されていない場合に、 データベースのバックアップで使用するバッファーのサイズを指定します。 バックアップ・ユーティリティーについての詳細は、 コマンド解説書 を参照してください。

データベースをバックアップすると、 まずデータが内部バッファーにコピーされます。 バッファーがいっぱいになると、 バッファー内のデータはバックアップ媒体に書き込まれます。

このバッファー・サイズを調整すると、 バックアップ・ユーティリティーのパフォーマンスは向上します。 並行しているデータベース操作のパフォーマンスへの影響は最小ですみます。

省略時の復元バッファー・サイズ (restbufsz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
1024 [ 16 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
復元ユーティリティーが呼び出されたとき

解放タイミング
復元ユーティリティーが処理を完了したとき

関連パラメーター

このパラメーターは、 復元ユーティリティーを呼び出した時点でバッファー・サイズが明示指定されていない場合に、 データベースの復元で使用するバッファーのサイズを指定します。 復元ユーティリティーについての詳細は、 コマンド解説書 を参照してください。

データベースの復元では、 まずデータがバックアップ媒体から内部バッファーにコピーされます。 バッファーがいっぱいになった時点でデータがターゲット・データベース媒体に書き出されます。

このバッファー・サイズを調整すると、 データベース復元ユーティリティーのパフォーマンスは向上します。 並行しているデータベース操作のパフォーマンスへの影響は最小ですみます。

ロック・リストの最大記憶域 (locklist)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
100 [ 4 〜 60 000 ]

OS/2 および NT ローカル・クライアントおよびリモート・クライアントをもつデータベース・サーバー
50 [ 4 〜 60 000 ]

OS/2 および NT ローカル・クライアントをもつデータベース・サーバー
25 [ 4 〜 60 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
最初のアプリケーションがデータベースに接続したとき

解放タイミング
最後のアプリケーションがデータベースから切断したとき

関連パラメーター

このパラメーターは、ロック・リストに割り振られる記憶域の量を示します。 データベースごとに 1 つのロック・リストがあります。 その中には、 データベースに並行して接続しているすべてのアプリケーションのロックが含まれています。 ロッキングとは、複数のアプリケーションがデータベースのデータに並行アクセスするのを制御するために、 データベース・マネージャーが使用する機構のことです。 行と表の両方をロックすることができます。 データベース・マネージャーは、 内部で使用するロックを獲得することもできます。

ロック・リストでは 1 つのロックにつき 36 または 72 バイトが必要ですが、 そのどちらであるかは、そのオブジェクトに関する他のロックが設定されているかどうかによって決まります。

あるアプリケーションが使用しているロック・リストのパーセント比率が maxlocks に達すると、 データベース・マネージャーはロック・エスカレーションを行い、 そのアプリケーションが設定しているロックを行から表に代えます (後で説明します)。 自動調整処理自体はそれほど時間がかかりませんが、 表全体をロックすると (行の場合と比較) 並行性が低下するため、 その表に以後アクセスする際のデータベース・パフォーマンスは全体として低下します。 ロック・リスト・サイズの制御について、 次のことを推奨します。

ロック・リストがいっぱいになると、 ロック・エスカレーションによって表ロックがさらに生成され、行ロックが少なくなるため、 データベース内の共用オブジェクトの並行性は低下し、パフォーマンスは低下します。 さらに、(表ロックの数が限定されているため) アプリケーション間のデッドロックが増え、 トランザクションがロール・バックされることがあります。 データベースのロック要求の最大数に達すると、 アプリケーションは SQLCODE -912 を受け取ります。

推奨事項: ロック・エスカレーションがパフォーマンス問題を引き起こす場合は、 このパラメーターまたは maxlocks パラメーターの値を大きくする必要があります。 ロック・エスカレーションが実行されているかどうかは、 データベース・システム・モニターを使って判別することができます。

詳細については、システム・モニター 手引きおよび解説書 の中の lock_escals (ロック・エスカレーション) モニター要素の説明を参照してください。

ロック・リストに必要なページ数は、次のステップで判別します。

  1. ロック・リストのサイズの下限を計算します。
      (512 * 36 * maxappls) / 4096
    

    512 はアプリケーションごとの平均ロック数を推定した数字です。 36 は、ロックがすでに設定されているオブジェクトに、 ロックを設定するのに必要なバイト数です。

  2. ロック・リストのサイズの上限を計算します。
      (512 * 72 * maxappls) / 4096
    

    72 はオブジェクトに対する最初のロックで必要なバイト数を表しています。

  3. データの並行性量を推定し、その推定値に基づいて、 計算して求めた上限と下限の間に収まる locklist の初期値を選択します。
  4. 後述されているように、データベース・システム・モニターを使ってこのパラメーターの値を調整します。

データベース・システム・モニターを使って、 指定されたトランザクションで設定されるロックの最大数を判断することができます。

詳細は、システム・モニター 手引きおよび解説書 の中の locks_held_top (保留するロックの最大数) モニター要素の説明を参照してください。

この情報を用いて、アプリケーションごとの推定ロック数の妥当性検査や調整を行うことができます。 妥当性検査を実行するには、 複数のアプリケーションをサンプルとして使い、 アプリケーション・レベルではなくトランザクション・レベルでモニター情報が提供されていることを確認する必要があります。

maxappls が増えた場合、 または実行中のアプリケーションが頻繁にコミットを行わない場合は、 locklist を大きくすることができます。

このパラメーターを変更してから、 アプリケーションの再バインドを考慮する必要があります (REBIND PACKAGE コマンドを使用)。

アプリケーションのパフォーマンスと影響する照会オプションについては、 第 10 部, アプリケーション・パフォーマンスのチューニングを参照してください。

パッケージ・キャッシュ・サイズ (pckcachesz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX 32 ビット・プラットフォーム
-1 [ -1, 32 〜 64 000 ]

UNIX 64 ビット・プラットフォーム
-1 [ -1, 32 〜 524 288 ]

OS/2 および Windows NT
-1 [ -1, 32 〜 64 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
データベースが初期設定されるとき

解放タイミング
データベースが遮断されるとき

このパラメーターは、データベース大域メモリーから割り振られ、 データベースに対する静的および動的 SQL ステートメントをキャッシュするために使用されます。 区分データベース システムでは、 各データベース区画にパッケージ・キャッシュが 1 つ設けられます。

パッケージをキャッシュしておくと、データベース・マネージャーは、 パッケージを再ロードするときにシステム・カタログにアクセスする必要がなくなるので、 または動的 SQL の場合はコンパイルの必要がなくなるので、 内部オーバーヘッドが小さくなります。 次のいずれかが生じるまで、 セクションはパッケージ・キャッシュに保持されます。

データベースに接続されているアプリケーションが何度も同じステートメントを使用するときは特に、 そのような静的または動的 SQL ステートメントのセクションをキャッシュすると、 パフォーマンスが向上します。 このことは、特にトランザクション処理アプリケーションで重要です。

サーバーまたは区分データベース環境で省略時値 (-1) を使用すると、 ページ割り振りの計算に使用される値は、 maxappls 構成パラメーターに指定されている値の 8 倍になります。 ただし、maxappls の 8 倍が 32 より小さい場合は、例外です。 この場合は、省略時値の -1 を指定すると、 pckcachesz は 32 に設定されます。

推奨事項: このパラメーターを調整するときは、パッケージ・キャッシュ用に予約される余分なメモリーを、 他の目的、たとえば、バッファー・プールなどに割り振った方が効果的かどうかを検討してください。 そのため、このパラメーターを調整する際には、ベンチマーク技法を使用してください。

最初は多くのセクションが使用されるが、その後反復されるセクションが少なくなる場合は、 特に、このパラメーターの調整が重要になります。 キャッシュが大き過ぎると、初期のセクションのコピーを 保持するためにメモリーが無駄に使用されることになります。

以下のモニター要素については、 システム・モニター 手引きおよび解説書 を参照してください。

これらのデータベース・システム・モニター要素を用いると、 この構成パラメーターを調整する必要があるかどうかを判別することができます。
注:パッケージ・キャッシュは作業キャッシュなので、 このパラメーターをゼロにすることはできません。 このキャッシュには、現在実行されている SQL ステートメントの全セクションを保持するのに十分なメモリーを割り振る必要があります。 現在必要なスペース以上のスペースが割り振られていると、 セクションがキャッシュされます。 これらのセクションは、必要になった時点でロードやコンパイルをせずに、 そのまま実行することができます。

pckcachesz パラメーターによって指定された限界は、 それほど厳格なものではありません。 メモリーが依然としてデータベース共用セットで使用できる状態であれば、 必要に応じてこの限界を超えることができます。 pkg_cache_size_top モニター要素を使用すると、 パッケージ・キャッシュの最大サイズを判別することができます。また、 pkg_cache_num_overflows モニター要素を使用すると、 pckcachesz パラメーターで指定した限界を超えた回数を判別することができます。

アプリケーション共用メモリー

以下のパラメーターは、 アプリケーションのために働くすべてのエージェント (調整およびサブエージェント) が使用する作業域を指定します。

アプリケーション制御ヒープ・サイズ (app_ctl_heap_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

ローカル・クライアントおよびリモート・クライアントをもつデータベース・サーバー
128 [1 〜 64 000]

ローカル・クライアントをもつデータベース・サーバー
64 [1 〜 64 000] (非 UNIX プラットフォームの場合)

128 [1 〜 64 000] (UNIX プラットフォームの場合)

ローカル・クライアントおよびリモート・クライアントをもつ区分化データベース・サーバー
256 [1 〜 64 000]

計測単位
ページ (4 KB)

割り振りタイミング
アプリケーションが開始するとき

解放タイミング
アプリケーションが終了するとき

関連パラメーター

このパラメーターは、 アプリケーション制御共用メモリーのための最大サイズを 4 KB ページ単位で決定します。 アプリケーション制御ヒープはこの共用メモリーから割り振られます。

アプリケーションが活動状態になるデータベースの各アプリケーションに対して、 1 つのアプリケーション制御ヒープが割り振られます (または、区分データベース・システムでは、 アプリケーションが活動状態になる各データベース区画に対して)。 このヒープは、データベース (またはデータベース区画) に、 アプリケーションに対する要求を受信するために、 最初のエージェントが接続処理時に割り振ります。 ヒープは、同一のアプリケーションのために作業するエージェントの間で情報を共用するために必要です。 (区分データベース環境では、データベース区画レベルで共用します。 データベース区画をまたいで共用が行われることはありません。)

このヒープは、 宣言済み一時表の記述子情報を保管するためにも使用されます。 明示的に除去されていないすべての宣言済み一時表の記述子情報は、 このヒープのメモリーに保持され、 宣言済み一時表を除去するまで除去することはできません。

注:

  1. 区分データベース環境では、エージェントおよびサブエージェントのために SQL ステートメントの実行セクションのコピーを格納するためにヒープが使用されます。 ただし、対称マルチプロセッサー・エージェント (SMP) のサブエージェントは、 他の環境のエージェントのように、 applheapsz を使用します。

  2. 割り振りは、intra_parallel パラメーターをオンに設定する他のデータベース、 および 1 より大きい値に設定される CURRENT DEGREE 特殊レジスターを持つ、他のデータベースの場合にのみ行われます。 CURRENT DEGREE 特殊レジスターの詳細については、 SQL 解説書 を参照してください。

推奨事項: 最初は、省略時値を使用して開始してください。 複雑なアプリケーションを実行する場合、 データベース区画が多数あるシステムの場合、 または宣言済み一時表を使用する場合は、 この値を大きく設定する必要があります。 必要となるメモリーの量は、 現在活動状態である宣言済み一時表が増えるとともに増加します。 多数の列を持つ宣言済み一時表は、 少しの列しか持たない表より表記述子のサイズが大きくなっています。 それで、アプリケーションの宣言済み一時表に多数の列があると、 アプリケーション制御ヒープの要求も大きくなります。

エージェント私用メモリー

次のパラメーターは、 各データベース・エージェントで使用されるメモリーの量を制御します。

私用エージェント・メモリーと、 データベース・マネージャーで割り振られるそれ以外のメモリーとの関係については、 DB2 でのメモリーの使用方法を参照してください。

分類ヒープ・サイズ (sortheap)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
256 [ 16 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
分類を実行するために必要になったとき

解放タイミング
分類が完了したとき

関連パラメーター
分類ヒープのしきい値 (sheapthres)

このパラメーターは、私用分類に使用される私用メモリー・ページの最大数、 または共用分類に使用される共用メモリー・ページの最大数を定義します。 分類が私用分類の場合は、このパラメーターはエージェント私用分類に影響します。 分類が共用分類の場合は、このパラメーターはデータベース共用メモリーに影響します。 各分類には、データベース・マネージャーによって必要に応じて割り振られる個別の分類ヒープがあります。 この分類ヒープは、データが分類される区域です。 最適化プログラムが指示する場合には、そのプログラムが提供する情報を用いて、 このパラメーターが指定するものより小さい分類ヒープが割り当てられます。

推奨事項:

分類ヒープのしきい値 (sheapthres)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX 32 ビット・プラットフォーム
20 000 [ 250 〜 2 097 152 ]

UNIX 64 ビット・プラットフォーム
20 000 [ 250 〜 2 147 483 647 ]

OS/2 および Windows NT
10 000 [ 250 〜 2 097 152 ]

計測単位
ページ (4 KB)

関連パラメーター
分類ヒープ・サイズ (sortheap)

私用および共用分類は、2 つの異なるメモリー・ソースからメモリーを使用します。 共用分類メモリー領域のサイズは、 sheapthres の値に基づくデータベースへの最初の接続時に静的に事前定義されます。 私用分類メモリー領域は無制限です。

sheapthres パラメーターは、 私用および共用分類に対して異なる方法で使用されます。

分類ヒープを使用するこれらの操作の例には、表がメモリーにあるハッシュ結合、 および操作が含まれます。

しきい値を明示的に定義すると、 データベース・マネージャーが多数の分類のためにメモリーを過度に使用しないようにすることができます。

推奨事項: このパラメーターを、 ユーザーのデータベース・マネージャー・インスタンス内の最大の sortheap パラメーターの妥当な倍数に設定できれば、理想的です。 このパラメーターは、インスタンス内のデータベースについて定義されている sortheap の最大値より少なくとも 2 倍は大きくなければなりません。

私用分類を行う場合で、システムにメモリーの制約がない場合は、 このパラメーターの理想値は、以下のステップを使用して計算することができます。

  1. 各データベースの通常の分類ヒープ使用法を計算します。
         (typical number of concurrent agents running against the database)
       * (sortheap, as defined for that database)
    
  2. 上記の結果を合計します。算出された分類ヒープの合計は、 インスタンス内のすべてのデータベースに関する通常の状況に対応しています。

SMP 環境で分類を行う場合の詳細については、 並列分類の方式を参照してください。

分類のパフォーマンスとメモリーの使用法とのバランスを取るためには、 ベンチマーク技法を使ってこのパラメーターを調整してください。 詳細については、第 31 章, ベンチマーク・テストを参照してください。 また、分類について詳しくは、分類も参照してください。

データベース・システム・モニターを使用して、分類活動をトラックすることもできます。

詳細については、 システム・モニター 手引きおよび解説書 の中の以下のモニター要素の説明を参照してください。

ステートメント・ヒープ・サイズ (stmtheap)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
2048 [ 128 〜 60 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
各ステートメントをプリコンパイルまたは結び付けているとき

解放タイミング
各ステートメントのプリコンパイルまたは結び付けが完了したとき

ステートメント・ヒープは、SQL ステートメントのコンパイル時に、 SQL コンパイラーの作業スペースとして使用されます。 このパラメーターは、この作業スペースのサイズを指定します。

この区域は永久的に割り振られるのではなく、SQL ステートメントを処理するたびに割り振られ、 また後で解放されます。 動的 SQL ステートメントの場合、この作業域はユーザー・プログラムの実行時に使用されます。 それに対して静的 SQL ステートメントの場合、この作業域はバインド処理時には使用されますが、 プログラムの実行時は使用されません。

推奨事項: このパラメーターの省略時値は、多くの場合、 受け入れることができます。 非常に大きな SQL ステートメントがある場合に、データベース・マネージャーが、 あるステートメントを最適化しようとしたときに (ステートメントが複雑すぎることを示す) エラーが戻された場合は、 エラー状態が解決されるまでこのパラメーターの値を一定の量 (256 または 1024 など) ずつ増やしていってください。

アプリケーション・ヒープ・サイズ (applheapsz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
128 [ 16 〜 60 000 ]

64 [ 16 〜 60 000 ] (複数区画)

計測単位
ページ (4 KB)

割り振りタイミング
エージェントがアプリケーション処理のために初期設定されるとき

解放タイミング
エージェントがアプリケーションのための仕事を完了したとき

関連パラメーター
アプリケーション制御ヒープ・サイズ (app_ctl_heap_sz)

このパラメーターは、 特定のエージェントまたはサブエージェントのためにデータベース・マネージャーが使用できる私用メモリーのページ数を定義します。

ヒープは、 エージェントまたはサブエージェントがアプリケーションのために初期設定されるときに割り振られます。 割り振られる量は、 要求を処理するためにエージェントまたはサブエージェントに与える必要のある最小値になります。 エージェントまたはサブエージェントは、 より大きな SQL ステートメントを処理するにはより大きなヒープ空間を必要とするため、 データベース・マネージャー は、必要に応じて、このパラメーターが指定する最大値までのメモリーを割り振ります。
注:区分データベース環境では、エージェントまたはサブエージェントのために、 SQL ステートメント実行セクションのコピーを格納するためにアプリケーション制御ヒープ (app_ctl_heap_sz) が使用されます。 ただし、SMP のサブエージェントは、他の環境でのエージェントのように、 applheapsz を使用します。

推奨事項: アプリケーション・ヒープに十分な記憶域がないことを示すエラーをアプリケーションが受け取った場合は、 このパラメーターの値を増やしてください。

アプリケーション・ヒープ (applheapsz) は、 エージェント私用メモリーから割り振られます。

統計ヒープ・サイズ (stat_heap_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
4384 [ 1096 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
RUNSTATS ユーティリティーを開始したとき

解放タイミング
RUNSTATS ユーティリティーが完了したとき

関連パラメーター

このパラメーターは、RUNSTATS コマンドを使って統計を収集するのに使用するヒープの最大サイズを示します。

推奨事項: 分散統計を収集しないとき、 または比較的小さい表についてだけ分散統計を収集するときは、 省略時値の使用が適切です。 最小値を選択すると 1 つまたは 2 つの列から成る表しかヒープに合わないので、 分散統計を収集する場合は、最小値の使用は推奨されていません

統計を収集する列の数に応じて、このパラメーターを調整してください。 比較的少数の列から成る小さな表の場合、 分散統計を収集するためのメモリーは少なくて済みます。 一方、多数の列を含む大きな表の場合は、 メモリーがさらに必要になります。 非常に大きな表の分散統計を収集するため大きな統計ヒープが必要な場合、 システムの活動が少ない期間に統計を収集することができます。 こうすると、他のユーザーのメモリー所要量を奪うことはありません。

照会ヒープ・サイズ (query_heap_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
1000 [ 2 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
アプリケーション (ローカルまたはリモート) がデータベースに接続したとき

解放タイミング
アプリケーションがデータベースから切断されたとき、 またはアプリケーションがインスタンスから切り離されたとき

関連パラメーター
アプリケーション・サポート層ヒープ・サイズ (aslheapsz)

このパラメーターは、照会ヒープのために割り振るメモリー量の最大値を指定します。 照会ヒープは、各照会をエージェントの私用メモリーに保管するために使用されます。 各照会の情報には、入出力 SQLDA、ステートメント・テキスト、 SQLCA、パッケージ名、作成者、セクション番号、および一貫性トークンが含まれます。 このパラメーターは、 アプリケーションが不必要にエージェントの仮想メモリーを大量に消費することがないようにするためのものです。

照会ヒープは、 ブロック・カーソル用に割り振られるメモリーのメモリー・ソースとしても使用されます。 このメモリーは、カーソル制御ブロックと完全解決の出力 SQLDA から構成されます。

最初に割り振られる照会ヒープのサイズは、 aslheapsz パラメーターで指定されたアプリケーション・サポート層ヒープのサイズと同じです。 照会ヒープ・サイズは、2 以上でかつ、 aslheapsz パラメーター以上である必要があります。 指定された要求を処理する場合にこの照会ヒープのサイズが十分でないと、 その要求に必要なサイズが再度割り振られます (query_heap_sz を超えることはありません)。 この新しい照会ヒープが aslheapsz の 1.5 倍より大きくなると、 照会が終了した時点で、 照会ヒープには aslheapsz のサイズが再割り振りされます。

推奨事項: 多くの場合、省略時値で十分です。 最低でも query_heap_sz には、 aslheapsz の 5 倍以上の値を設定してください。 そのように設定すると、aslheapsz より大きな照会が可能になり、 同時に 3 つまたは 4 つのブロック・カーソルをオープンするためのメモリーを追加することができます。

LOB が非常に大きい場合は、その LOB を収容できるだけの大きさの照会ヒープを提供するために、 このパラメーターの値を大きくする必要が生じる場合があります。

DRDA ヒープ・サイズ (drda_heap_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
128 [ 16 〜 60 000 ]

計測単位
ページ (4 KB)

割り振りタイミング

解放タイミング
DRDA AR がデータベースから切断したとき

このパラメーターは、 DB2 コネクトおよび DRDA アプリケーション・サーバー・サポート機能が使用するメモリーとして割り振られるページ数を指示します。 このヒープから割り振られるメモリーの量は、 次の項目により決まります。

推奨事項: DRDA ヒープが不足であるというエラー・コードが出ない限り、 省略時値を使用してください。

UDF 共用メモリー・セット・サイズ (udf_mem_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
256 [ 128 〜 60 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
UDF が開始するとき

解放タイミング
UDF が完了したとき

このパラメーターは、 分離されたユーザー定義関数 (UDF) と分離されていない UDF で共通です。 分離された UDF の場合、 データベース・プロセスと UDF とで共用するメモリーの省略時割り振りを指定します。 単一区分データベース環境では、 共用メモリー・セットはただ 1 つだけです。 区分データベース環境では、 各データベース区画サーバーに 1 つの共用メモリー・セットがあり、 そのサーバーで実行されるすべてのアプリケーション・エージェントおよびサブエージェントが、 同じ共用メモリー・セットを使用します。

分離されていない UDF の場合は、私用メモリー・セットのサイズを指定します。 単一区画データベース環境では、ヒープは私用メモリーから割り振られます。 区分データベース環境では、 ヒープは各データベース区画サーバーのアプリケーション・グローバル・メモリーから割り振られ、 そのデータベース区画サーバーのアプリケーションのために実行されるエージェントおよびサブエージェントがこの同じ共用メモリー・セットを使用します。

分離されている UDF でも分離されていない UDF でも、 このメモリーは UDF とデータベースの間でデータを受け渡しするために使用されます。

UDF がアプリケーションで使用されない場合は、メモリーは割り当てられません。 同じアプリケーションで、分離されている UDF と分離されていない UDF の両方を実行する場合は、 メモリー割り振りが 2 つ行われることになります。 1 つは分離された UDF 用、もう 1 つは分離されていない UDF 用です。

ユーザー定義関数については、 アプリケーション開発の手引き および SQL 解説書 を参照してください。

推奨事項: 省略時設定は、 LOB データを UDF に渡す場合を除いて他のどのような状況にも十分対応できるはずです。 LOB データを UDF に渡す状況では、 メモリーの割り振り量を増やす必要が生じることがあります。 このパラメーターには、 入力引き数のサイズおよび外部関数の結果より最低でも 2 ページは大きな値を設定してください。
注:UDF のメモリー要件は付加的なものであるため、 このパラメーターの最適設定は、アプリケーション内で参照される UDF の数に影響されます。

エージェント・スタック・サイズ (agent_stack_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]

OS/2
64 [ 8 〜 1000 ]

Windows NT
16 [ 8 〜 1000 ]

計測単位
ページ (4 KB)

割り振りタイミング
エージェントがアプリケーション処理のために初期設定されるとき

解放タイミング
エージェントがアプリケーションのための仕事を完了したとき

エージェント・スタックは、 各エージェント用に DB2 が割り振る仮想メモリーです。 このメモリーは、 SQL ステートメントを処理するために必要になると、 コミットされます。 このパラメーターを使用すると、 特定のアプリケーションの集まりに合わせてサーバーのメモリー使用状況を最適化することができます。 単純な照会と比べて、 照会が複雑になればなるほど使用するスタック・スペースは大きくなります。

このパラメーターは UNIX ベースのプラットフォームには適用されません。

推奨事項: ほとんどの場合、 省略時のスタック・サイズを使用することができます。 ユーザーの環境で非常に複雑な照会が多くなったときだけ、 このパラメーターの値を大きくする必要が生じます。 スタック・サイズの大きさが SQL ステートメントを処理するのに十分ではないと、 db2diag.log ファイルにエラー項目がログに記録されて、SQL コードが出されます。 agent_stack_sz を大きくして、 データベース・インスタンスを再始動する必要があります。

ユーザーの環境が次の条件を満たしていると、スタック・サイズを小さくして、 他のクライアントが利用できるアドレス空間を広げることができます。

エージェント・スタックのサイズと並行クライアントの数は、反比例しています。 スタック・サイズを大きくすると、実行可能な並行クライアントの数は減ります。 これは、 アドレス空間が OS/2 および Windows NT プラットフォーム上で限定されているために発生します。 たとえば、OS/2 では、400 MB のアドレス空間があるという前提になります (この量は、 config.sys ファイルによって異なります)。 agent_stack_sz の値を 1 MB に設定すると、 400 以上のエージェントを入手することはできません。 (実際には、バッファー・プールなどアドレス空間の他の要件のために、 入手できるエージェントはおそらくそれ以下になります。) つまり、maxagents をより大きな値に設定 (たとえば 5000 など) に設定すれば、この限界に到達することはありません。

コミットされる私用メモリーの最小値 (min_priv_mem)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
32 [ 32 〜 112 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
データベース・マネージャーが開始したとき

解放タイミング
データベース・マネージャーが停止したとき

関連パラメーター
私用メモリーしきい値 (priv_mem_thresh)

このパラメーターは、データベース・マネージャー・インスタンスの開始 (db2start) 時に、 データベース・サーバー・プロセスが私用仮想メモリーとして予約するページの数を指定します。 追加の私用メモリーが必要であれば、 サーバーはオペレーティング・システムからメモリーをさらに獲得しようと試みます。

このパラメーターは UNIX ベースのシステムには適用されません。

推奨事項: 省略時値を使用してください。

データベース・サーバーにより多くのメモリーをコミットしたい場合だけ、 この値を変更してください。 このようにすると、 割り振り時間の節約になります。 ただし、この値を大きくすると DB2 以外のアプリケーションのパフォーマンスに影響することがあるので、 この値を大きく設定し過ぎないように注意してください。

私用メモリーしきい値 (priv_mem_thresh)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
1296 [ -1; 32 〜 112 000 ]

32 [ -1; 32 〜 112 000 ] (ローカル・クライアントをもつサテライト・データベース・サーバー )

計測単位
ページ (4 KB)

関連パラメーター
コミットされる私用メモリーの最小値 (min_priv_mem)

このパラメーターは、未使用のエージェント私用メモリーのうち、 新しく開始されるエージェントが使用できるよう、割り振られたままにしておく量を決定します。 これは UNIX ベースのシステムには適用されません。

エージェントが終了すると、データベース・マネージャーは、 そのエージェントが使用していたメモリーをすべて割り振り解除するのではなく、 次の式で計算された超過メモリー割り振り だけを割り振り解除します。

  割り振られた私用メモリー -
  (使用された私用メモリー + priv_mem_thresh)

この式の結果が負の数になった場合は、何のアクションも実行されません。

次の表は、メモリーの割り振りと割り振り解除が行われる時点を示す例です。 この例では、 priv_mem_thresh の任意の設定値として 100 を使います。
アクションの説明 割り振られる メモリー 使用される メモリー
多数のエージェントが実行中。メモリーは割り振られている。 1000 1000
新しいエージェントが開始され、100 ページのメモリーを使用した。 1100 1100
200 ページのメモリーを使用していたエージェントが終了した。 (100 ページのメモリーが解放されましたが、 将来の使用のために 100 ページが割り振られたままであることに注意してください。) 1000 900
50 ページのメモリーを使用していたエージェントが終了した。 (50 ページのメモリーが解放されましたが、 余分な 100 ページが割り振られたままであることに注意してください。 既存のエージェントで使用されている量と比較してください。) 950 850
新しいエージェントが開始され、 150 ページのメモリーが必要になった。 (150 ページのうち 100 ページはすでに割り振られているので、 データベース・マネージャーはこのエージェント用に 50 ページを追加割り振りするだけで済みます。) 1000 1000

"-1" に設定すると、 このパラメーターでは min_priv_mem パラメーターの値が使用されます。

推奨事項: このパラメーターを設定するときは、 同じマシン上にある他のプロセスのメモリー要件を考慮するのと同時に、 クライアントの接続 / 切断パターンについても考える必要があります。

多くのクライアントが並行してデータベースに接続する時間が短いのに、 しきい値を高めに設定すると、未使用のメモリーをコミット解除し、 他のプロセスで使用可能にすることができなくなります。 その結果、メモリー管理は低下し、 その影響はメモリーを必要としている他のプロセスにまで及びます。

一定の数のクライアントが並行しており、その数がときどき変化する場合、 しきい値を高めに設定すると、クライアント・プロセスが使用できるメモリーを確保し、 メモリーの割り振りおよび割り振り解除で生じるオーバーヘッドを減らすことができます。

エージェント / アプリケーション通信メモリー

次のパラメーターは、 ユーザー・アプリケーションとエージェント・プロセスとの間でデータを渡すために割り振られるメモリーの量を制御します。

エージェント / アプリケーション共用メモリーと、 データベース・マネージャーで割り振られるそれ以外のメモリーとの関係については、 DB2 でのメモリーの使用方法を参照してください。

アプリケーション・サポート層ヒープ・サイズ (aslheapsz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
15 [ 1 〜 524 288 ]

計測単位
ページ (4 KB)

割り振りタイミング
データベース・マネージャーのエージェント・プロセスがローカル・アプリケーション用に開始するとき

解放タイミング
データベース・マネージャーのエージェント・プロセスが終了したとき

関連パラメーター
照会ヒープ・サイズ (query_heap_sz)

アプリケーション・サポート層ヒープは、 ローカル・アプリケーションと関連エージェントとの間にある通信バッファーを表しています。 このバッファーは、 開始されるデータベース・マネージャー・エージェントごとに、共用メモリーとして割り振られます。

データベース・マネージャーへの要求または関連応答がバッファーに収まらない場合、 それらの要求または応答は 2 つ以上の送受信の対に分けられます。 このバッファーのサイズは、 ほとんどの要求をシングル送受信の対で処理できるように設定してください。 要求のサイズは、 次のものを保持するのにどれくらいの記憶域が必要かによって決まります。

このパラメーターは、通信バッファーの他にも、 ブロック・カーソルがオープンしているときの入出力ブロック・サイズも指定することができます。 ブロック・カーソル用のメモリーはアプリケーションの私用アドレス空間から割り振られます。 したがって、各アプリケーション・プログラムに割り振る私用メモリーの量として、 最適な値を指定する必要があります。 データベース・クライアントが、アプリケーションの私用メモリーから、 ブロック・カーソル用のスペースを割り振ることができない場合は、 非ブロック・カーソルがオープンされます。

ローカル・アプリケーションから送信されたデータはデータベース・マネージャーに受信され、 照会ヒープから割り振られた連続メモリーに入れられます。 照会ヒープの初期サイズ (ローカル・クライアントとリモート・クライアントの両方) は、 aslheapsz パラメーターを使って決定します。 照会ヒープの最大サイズは、 query_heap_sz パラメーターで定義されます。

推奨事項: アプリケーションの要求が小さい場合が多く、 しかもアプリケーションがメモリー制約のあるシステムで実行される場合は、 このパラメーターの値を小さくすることができます。 照会は通常は非常に大きく、複数の送受信要求が必要になり、 かつ使用するシステムのメモリーが制限されている場合には、 このパラメーターの値を増やすこともできます。

次の式を使って、aslheapsz のページ数を計算します。

    aslheapsz >= ( sizeof(input SQLDA)
                 + sizeof(each input SQLVAR)
                 + sizeof(output SQLDA)
                 + 250 ) / 4096

このパラメーターがブロック・カーソルの数や潜在的なサイズに与える影響についても考慮する必要があります。 大きな行ブロックの場合、転送する行の数またはサイズが大きい (たとえば、 データの量が 4096 バイトより大きい) と、 パフォーマンスは向上する可能性があります。 しかし、レコード・ブロックを大きくすると、 個々の接続の実効ページ・セットのサイズも大きくなってしまいます。

さらに、レコード・ブロックを大きくすると、 アプリケーションが実際に要求する数より多くの FETCH 要求が出されます。 FETCH 要求の数を制御するには、 ユーザーのアプリケーションで SELECT ステートメントの OPTIMIZE FOR 文節を使用します。 OPTIMIZE FOR 文節については、 OPTIMIZE FOR n ROWS 文節を参照してください。

クライアント入出力ブロック・サイズ (rqrioblk)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
32 767 [ 4096 〜 65 535 ]

計測単位
バイト

割り振りタイミング

解放タイミング

関連パラメーター
DOS リクエスター入出力ブロック・サイズ (dos_rqrioblk)

このパラメーターは、 リモート・アプリケーションとデータベース・サーバーのデータベース・エージェントとの間に置かれる通信バッファーのサイズを指定します。 データベース・クライアントから、リモート・データベースへの接続要求が発行されると、 クライアント上でこの通信バッファーが割り振られます。 データベース・サーバーでは、接続が確立されてクライアント上の rqrioblk の値をサーバーが判別できるようになるまで、 32767 バイトの通信バッファーが最初に割り振られます。 サーバーがこの値を判別できるようになった後で、 クライアントのバッファーが 32767 バイトになっていないと、 通信バッファーは再割り振りされます。

このパラメーターは、通信バッファーの他にも、 ブロック・カーソルがオープンされているときのデータベース・クライアントの入出力ブロック・サイズも指定することができます。 ブロック・カーソル用のメモリーはアプリケーションの私用アドレス空間から割り振られます。 したがって、各アプリケーション・プログラムに割り振る私用メモリーの量として、 最適な値を指定する必要があります。 データベース・クライアントが、アプリケーションの私用メモリーから、 ブロック・カーソル用のスペースを割り振ることができない場合は、 非ブロック・カーソルがオープンされます。

推奨事項: 非ブロック・カーソルの場合は、 1 つの SQL ステートメントで転送したいデータ (ラージ・オブジェクト・データなど) が非常に大きくて、 省略時値では不十分であるときなどが、このパラメーターの値を増す場合です。

このパラメーターがブロック・カーソルの数や潜在的なサイズに与える影響についても考慮する必要があります。 大きな行ブロックの場合、転送する行の数またはサイズが大きい (たとえば、 データの量が 4096 バイトより大きい) と、 パフォーマンスは向上する可能性があります。 しかし、レコード・ブロックを大きくすると、 個々の接続の実効ページ・セットのサイズも大きくなってしまいます。

さらに、レコード・ブロックを大きくすると、 アプリケーションが実際に要求する数より多くの FETCH 要求が出されます。 FETCH 要求の数を制御するには、 ユーザーのアプリケーションで SELECT ステートメントの OPTIMIZE FOR 文節を使用します。 OPTIMIZE FOR 文節の詳細については、 OPTIMIZE FOR n ROWS 文節を参照してください。

DOS リクエスター入出力ブロック・サイズ (dos_rqrioblk)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
4096 [ 4096 〜 65 535 ]

計測単位
バイト

割り振りタイミング

解放タイミング

関連パラメーター
クライアント入出力ブロック・サイズ (rqrioblk)

このパラメーターは、 DOS/Windows 3.1 アプリケーションとデータベース・サーバーのデータベース・エージェントとの間にある通信バッファーのサイズを指定します。 このパラメーターは rqrioblk パラメーターと似ていますが、 DOS/Windows 3.1 クライアントで使用されるブロックに、 別の値を設定できる点が異なります。 DB2 構成ファイルでは、 rqrioblk パラメーター (32 ビット Windows、OS/2、 および UNIX クライアント用) および dos_rqrioblk パラメーター (DOS および Windows 3.1 クライアント用) の両方を設定することができます。

このパラメーターは、通信バッファーの他にも、 ブロック・カーソルがオープンされているときのデータベース・クライアントの入出力ブロック・サイズも指定することができます。 ブロック・カーソル用のメモリーはアプリケーションの私用アドレス空間から割り振られます。 したがって、各アプリケーション・プログラムに割り振る私用メモリーの量として、 最適な値を指定する必要があります。 データベース・クライアントが、アプリケーションの私用メモリーから、 ブロック・カーソル用のスペースを割り振ることができない場合は、 非ブロック・カーソルがオープンされます。

推奨事項: 非ブロック・カーソルの場合は、 1 つの SQL ステートメントで転送したいデータ (ラージ・オブジェクト・データなど) が非常に大きくて、 省略時値では不十分であるときなどが、このパラメーターの値を増す場合です。

このパラメーターがブロック・カーソルの数や潜在的なサイズに与える影響についても考慮する必要があります。 大きな行ブロックの場合、転送する行の数またはサイズが大きい (たとえば、 データの量が 4096 バイトより大きい) と、 パフォーマンスは向上する可能性があります。 しかし、レコード・ブロックを大きくすると、 個々の接続の実効ページ・セットのサイズも大きくなってしまいます。

さらに、レコード・ブロックを大きくすると、 アプリケーションが実際に要求する数より多くの FETCH 要求が出されます。 FETCH 要求の数を制御するには、 ユーザーのアプリケーションで SELECT ステートメントの OPTIMIZE FOR 文節を使用します。 OPTIMIZE FOR 文節の詳細については、 OPTIMIZE FOR n ROWS 文節を参照してください。

データベース・マネージャー インスタンス・メモリー

次のパラメーターは、 インスタンス・レベルで割り振られて使用されるメモリーを制御します。

データベース・システム・モニター・ヒープ・サイズ (mon_heap_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
56 [ 0 〜 60 000 ]

OS/2 および Windows NT ローカル・クライアントおよびリモート・クライアントをもつデータベース・サーバー および ローカル・クライアントをもつサテライト・データベース・サーバー
24 [ 0 〜 60 000 ]

OS/2 および Windows NT ローカル・クライアントをもつデータベース・サーバー
12 [ 0 〜 60 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
db2start コマンドによりデータベース・マネージャーが開始されたとき

解放タイミング
db2stop コマンドによりデータベース・マネージャーが停止したとき

関連パラメーター
省略時 データベース・システム・モニター・スイッチ (dft_monswitches)

このパラメーターは、 データベース・システム・モニターのデータ用に割り振るメモリー量をページ単位で判別します。 スナップショットの獲得、モニター・スイッチの調整、モニターのリセット、 またはイベント・モニターの活動化などの、データベース・モニター活動を実行すると、 メモリーがモニター・ヒープから割り振られます。

ゼロに設定すると、データベース・マネージャーはデータベース・システム・モニター・データを収集しません。

推奨事項: モニター活動に必要なメモリーの量は、 スイッチが設定されたモニター・アプリケーション (スナップショットを獲得するアプリケーションまたはイベント・モニター) の数とデータベース活動のレベルによって異なります。

モニター・ヒープで必要なページ数は、次の式を使って概算することができます。

  ( モニター・アプリケーションの数 + 1 ) *
  ( データベースの数 *
    (800 + ( アクセスされた表の数 * 20 )
     + ( ( 接続されたアプリケーションの数 + 1) *
         (200 + (表スペースの数 * 100) ) ) ) )
  / 4096

ヒープ中の使用可能メモリーが足りなくなると、次のいずれかの事態が生じます。

ディレクトリー・キャッシュ・サポート (dir_cache)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
Yes [ Yes; No ]

割り振りタイミング

解放タイミング

dir_cache を「yes」に設定すると、データベース、ノード、 および DCS ディレクトリー・ファイルがメモリーにキャッシュされます。 ディレクトリー・キャッシュを使用すると、ディレクトリー・ファイルの入出力が省略され、 ディレクトリー情報を検索するためのディレクトリー検索が最小化されるので、 接続コストは減少します。 ディレクトリー・キャッシュには次の 2 つのタイプがあります。

注:サポートされている Windows 環境では、 私用キャッシュだけが使用されます。

私用キャッシュの場合、アプリケーションが最初の接続を発行すると、 各ディレクトリー・ファイルが読み取られ、 そのアプリケーションに関する情報が私用メモリーにキャッシュされます。 その後の接続要求では、 アプリケーション・プロセスはこのキャッシュを使用します。 アプリケーション・プロセスが活動している間は、キャッシュは保守されます。 私用キャッシュにデータベースがない場合は、 ディレクトリー・ファイルで情報が検索されますが、 キャッシュ自体は更新されません。 アプリケーションがディレクトリー項目を修正すると、 アプリケーションが次回の接続を発行した時点で、 このアプリケーション用のキャッシュが最新表示されます。 他のアプリケーションに属する私用キャッシュは最新表示されません。 アプリケーションがディレクトリー項目を修正すると、 アプリケーションが次回の接続を発行した時点で、 このアプリケーション用のキャッシュが最新表示されます。 (コマンド行プロセッサー・セッションが使用するディレクトリー・キャッシュを最新表示するには、 db2 terminate コマンドを出してください。)

共用キャッシュの場合、データベース・マネージャー・インスタンスが開始(db2start)されると、 各ディレクトリー・ファイルが読み取られ、情報が共用メモリーにキャッシュされます。 このキャッシュは、データベース・マネージャー・プロセスの一部により使用され、 インスタンスが停止するまで(db2stop)保守されます。 アプリケーション・プロセスが終了すると、キャッシュも解放されます。 インスタンスの実行中に、 共用キャッシュが最新表示されることはありません。

推奨事項: ディレクトリー・ファイルが頻繁には変更されない場合、 パフォーマンスが重要事項であれば、ディレクトリー・キャッシュを使用してください。

さらに、リモート・クライアントで、 アプリケーションが複数の異なる接続要求を発行する場合には、 ディレクトリーをキャッシュしておくと効果的です。 この場合、キャッシュを使うと、 シングル・アプリケーションがディレクトリー・ファイルを読み取る回数が減少します。

ディレクトリー・キャッシュをオンにすると、 データベース・システム・モニター・スナップショットを獲得するときのパフォーマンスも向上します。 スナップショットを呼び出すときは、データベースの別名ではなく、 データベースの名前を明示的に参照する必要があります。
注:データベース・マネージャーを開始した後にデータベースがカタログ化、カタログ解除、作成、 または除去された場合、ディレクトリー・キャッシュがオンになっていると、 スナップショットを呼び出したときにエラーが発生することがあります。

監査バッファー・サイズ (audit_buf_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
0 [ 0 〜 65 000 ]

計測単位
ページ (4 KB)

割り振りタイミング
DB2 始動時

解放タイミング
DB2 停止時

このパラメーターは、 データベース監査時に使用されるバッファー・サイズを指定します。 監査機能について詳しくは、 管理の手引き: 計画 にある『DB2 アクティビティーの監査』を参照してください。

このパラメーターの省略時値はゼロ (0) です。 値がゼロ (0) の場合、 監査バッファーは使用されません。 値がゼロ (0) より大きければ、監査バッファー用のスペースが割り振られます。 監査バッファーでは、監査機能によって生成される監査レコードが挿入されます。 値に 4 KB ページを乗算すると、 監査バッファーに割り振られるスペース量になります。 監査バッファーを動的に割り振ることはできません。 このパラメーターの新しい値を有効にするには、 DB2 を停止して再始動する必要があります。

このパラメーターを省略時値からゼロ (0) よりも大きい一定の値に変更すれば、監査機能により、 監査レコードを生成するステートメントの実行に対して非同期でディスクにレコードが書き込まれます。 こうすれば、 パラメーター値をゼロ (0) のままにしておく場合よりも DB2 のパフォーマンスが向上します。 値がゼロ (0) であれば、監査レコードを生成するステートメントの実行と同期で (同時に)、 監査機能がディスクにレコードを書き込むことになります。 監査時の同期操作は、 DB2 で実行するアプリケーションのパフォーマンスを低下させます。

Java インタープリター・ヒープの最大サイズ (java_heap_sz)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
512 [0 〜 4 096]

計測単位
ページ (4 KB)

割り振りタイミング
Java アプリケーションが開始するとき

解放タイミング
Java アプリケーションが完了したとき

関連パラメーター
Java 開発キット 1.1 インストール・パス (jdk11_path)

このパラメーターは、 Java インタープリターが使用するヒープの最大サイズを決定します。

各 DB2 プロセスに 1 つのヒープ (UNIX ベースのプラットフォームの各エージェントまたはサブエージェントに 1 つずつ、 および他のプラットフォームのインスタンスに 1 つずつ)、さらに、 分離された UDF と分離されたストアード・プロシージャー・プロセスごとに 1 つずつヒープがあります。 どの場合でも、 Java UDF またはストアード・プロシージャーを実行するエージェントまたはプロセスだけがこのメモリーを割り振ります。 区分データベース・システムでは、 ヒープは、データベース区画サーバーの数で乗じられます。

ロック

次のパラメーターは、ユーザーの環境でのロック管理を制御します。

ロック・リストの最大記憶域 (locklist)も参照してください。

ロック は、 データベース・マネージャーがロックを使ってデータの保全性を確保する方法を概説しています。

デッドロック検査の時間間隔 (dlchktime)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
10 000(10 秒)[ 1000 〜 600 000 ]

計測単位
ミリ秒

関連パラメーター

デッドロックは、同一データベースに接続した 2 つ以上のアプリケーションが、 リソースが空くのを無限に待っているときに生じます。 どのアプリケーションも、 他のアプリケーションが必要としているリソースを保持しているため、 この待ち状態は永久に解決されません。

デッドロック検査間隔は、 データベースに接続しているすべてのアプリケーションの間でデッドロックが生じていないかどうかを、 データベース・マネージャーが検査する頻度を定義します。

注:

  1. 区分データベース環境では、 このパラメーターはカタログ・ノードにだけ適用されます。

  2. 区分データベース環境では、 2 番目の反復の後まではデッドロックのフラグが付けられません。

推奨事項: このパラメーターを大きくすると、 デッドロック検査の頻度が低下するので、 デッドロックが解決されるまでアプリケーション・プログラムが待たなければならない時間は長くなります。

このパラメーターを小さくすると、デッドロック検査の頻度が高まるので、 デッドロックが解決されるまでアプリケーション・プログラムが待たなければならない時間は短くなりますが、 データベース・マネージャーがデッドロックを検査するのにかかる時間は長くなります。 デッドロックの間隔が極端に短いと、 データベース・マネージャーはデッドロック検出を頻繁に実行することになるので、 実行時のパフォーマンスは低下します。 並行性を高めるためにこのパラメーターを低く設定する場合、 不必要なロック・エスカレーションが行われないよう maxlockslocklist を適切に設定する必要があります。 適切に設定されていないと、 ロック競合がさらに発生し、デッドロック状態がより多く発生することになります。

自動調整前のロック・リストの最大パーセント (maxlocks)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
10 [ 1 〜 100 ]

OS/2 および Windows NT
22 [ 1 〜 100 ]

計測単位
パーセント

関連パラメーター

ロック・エスカレーションとは、行ロックの代わりに表ロックを設定し、 リスト中のロック数を減らす処理です。 このパラメーターは、 あるアプリケーションにより設定されたロック・リストのパーセント率を定義し、 そのパーセント数に達するとデータベース・マネージャーが自動調整を行うようにします。 あるアプリケーションにより設定されたロックの数が、 ロック・リストの合計サイズに関するこのパーセント数に達すると、 そのアプリケーションにより設定されたロックについて自動調整が行われます。 ロック・リストのスペースが足りなくなったときも、 ロック・エスカレーションが行われます。

データベース・マネージャーは、ロック・リストでアプリケーションのロックについて調べ、 行ロックが一番多い表を見つけることにより、 どのロックを自動調整するかを判断します。 それらの行ロックの代わりにシングル表ロックを設定して、 maxlocks の値より低くなると、 ロック・エスカレーションは停止します。 まだ高いようであれば、 ロック・リストのパーセント数が maxlocks の値より低くなるまでロック・エスカレーションは継続されます。 maxlocks パラメーターに maxappls パラメーターを掛けた値は、 100 より小さくはなりません。

推奨事項: maxlocks を設定するときは、 ロック・リスト (locklist) のサイズも考慮してください。

   maxlocks = 100 *
              (アプリケーションごとに 512 ロック
              * ロックごとに 32 バイト
              * 2) / (locklist * 4096 バイト)

この例では、任意のアプリケーションが、平均の 2 倍のロック数を設定できます。

並行して実行しているアプリケーションが少ないと、 ロック・リストのスペースで競合が生じることはあまりなくなるので、 maxlocks を大きくすることができます。

この構成パラメーターのトラックと調整を行うために、データベース・システム・モニターを使用することもできます。

詳細は、システム・モニター 手引きおよび解説書 の中の locks_held_top (保留するロックの最大数) モニター要素の説明を参照してください。

最適化プログラムはアクセス・パスの判別にこのパラメーターを使うため、 このパラメーターを介してロック・エスカレーションの制御を行うのは、 最適化プログラムには重要なことです。 このパラメーターを変更してから、アプリケーションの再バインドを考慮する必要があります (REBIND PACKAGE コマンドを使用)。

ロック・タイムアウト (locktimeout)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
-1 [-1; 0 〜 30 000 ]

計測単位

関連パラメーター

このパラメーターは、 ロックを獲得する場合にアプリケーションが待機する時間を秒単位で指定します。 これにより、アプリケーションの大域デッドロックを防ぐことができます。

このパラメーターを 0 に設定すると、 ロックは待機されません。 この状況下で要求時に使用できるロックがなければ、 アプリケーションはただちに -911 を受け取ります。

このパラメーターを -1 に設定すると、 ロック・タイムアウト検出はオフになります。 この状況下では、以下のいずれかの条件が発生するまで、 ロックは (要求時に使用できるロックがない限り) 待機されます。

推奨事項: トランザクション処理 (OLTP) 環境では、 初期値 30 秒から始めることができます。 照会しか行わない環境では、もう少し高い値から始めることができます。 どちらの場合も、ベンチマーク手法を使ってこのパラメーターを調整してください。

データ・リンク・マネージャーを使用して作業するときに、 データ・リンク・マネージャー (dlfm) インスタンスの db2diag.log 内にロック・タイムアウトが存在する場合は、 locktimeout の値を増やす必要があります。 また、 locklist の値を増やすことも考慮する必要があります。

トランザクションの停止 (ユーザーがワークステーションから離れたことなどの理由で) などの異常事態が発生した場合に、 待ち状態をすばやく検出できるよう、この値を設定してください。 作業負荷のピーク時はロックの待ち時間も長くなりますが、それが原因で、 有効なロック要求がタイムアウトになることがないよう、 この値を十分高く設定してください。

データベース・システム・モニターを使用すると、 アプリケーション (接続) でロック・タイムアウトが発生した回数、 または接続していたすべてのアプリケーションで生じたタイムアウト状態をデータベースが検出した回数をトラックすることができます。 詳細は、システム・モニター 手引きおよび解説書 の中の locks_timeouts (ロック・タイムアウトの数) モニター要素に関する説明を参照してください。

lock_timeout モニター要素の値が高い場合は、 次の原因が考えられます。

このパラメーターの使用については、ロックの待機とタイムアウトを参照してください。

入出力および記憶域

次のパラメーターは、 データベースの操作に伴う入出力および記憶域のコストを制御します。

ページ変更しきい値 (chngpgs_thresh)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
60 [ 5 〜 99 ]

計測単位
パーセント

関連パラメーター
非同期ページ・クリーナーの数 (num_iocleaners)

非同期ページ・クリーナーは、 データベース・エージェントでバッファー・プールのスペースが必要になる前に、 変更されたページをバッファー・プールからディスクに書き込みます。 つまり、エージェントは、ページを読み取る前に変更ページが書き出されるのを待つ必要がないので、 アプリケーションのトランザクションはより高速に実行することができます。

このパラメーターは、非同期ページ・クリーナーが現在活動していない場合に、 このクリーナーを開始するための変更ページのレベル (パーセント比率) を指定することができます。 ページ・クリーナーが開始されると、 ディスクに書き込むページのリストが作成されます。 ディスクへの書き込みが完了すると、ページ・クリーナーは再び非活動になり、 次のトリガーにより開始されるまで待機します。

読み取り専用 (たとえば、照会) 環境では、 これらのページ・クリーナーは使用されません。

推奨事項: 更新トランザクション作業負荷が多量にあるデータベースの場合、 このパラメーター値を省略時値以下に設定すると、 バッファー・プールにクリーン・ページを十分確保することができます。 省略時値よりパーセント比率を高くすると、 データベースに非常に大きな表が少ししかない場合は、パフォーマンスが向上します。

非同期ページ・クリーナーの数 (num_iocleaners)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
1 [ 0 〜 255 ]

計測単位
カウンター

関連パラメーター

このパラメーターは、データベースあたりの非同期ページ・クリーナーの数を指定します。 ページ・クリーナーは、データベース・エージェントでバッファー・プールのスペースが必要になる前に、 変更されたページをバッファー・プールからディスクに書き込みます。 つまり、エージェントは変更されたページがディスクに書き込まれるのを待たずに、 ページを読み取ることができます。 結果として、 アプリケーションに含まれるトランザクションの実行速度は速くなります。

パラメーターをゼロ (0) に設定すると、ページ・クリーナーは開始されません。 その結果、バッファー・プールからディスクへの書き込みは、 すべてデータベース・エージェントが行うようになります。 多数の物理記憶域に分かれて保管されているデータベースの場合、 それらの装置のいずれかがアイドル状態にある可能性は高いため、 このパラメーターの設定はパフォーマンスに重大な影響を及ぼします。 ページ・クリーナーを構成しないと、ユーザーのアプリケーションでは、 ログがいっぱいになる状態が定期的に発生することになる場合があります。

データベースに対して実行するアプリケーションが、 主にデータを更新するトランザクションから構成されている場合、 クリーナーの数を増やすとパフォーマンスは向上します。 ページ・クリーナーの数を増やすと、 ディスク上のデータベースの内容はいつでも最新のものになるので、 電源異常などのソフト障害から回復する時間も短くなります。

推奨事項: このパラメーターを設定するときは、 以下の要素を考慮に入れてください。

データベース・システム・モニターを使用すると、イベント・モニターから与えられる、 バッファー・プールからの書き出し活動に関する情報を用いて、 この構成ファイルを調整することができます。

詳細については、 システム・モニター 手引きおよび解説書 の中の以下のモニター要素の説明を参照してください。

入出力サーバー数 (num_ioservers)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
3 [ 1 〜 255 ]

1 [ 1 〜 255 ] (ローカル・クライアントをもつサテライト・データベース・サーバー )

計測単位
カウンター

割り振りタイミング
アプリケーションがデータベースに接続したとき

解放タイミング
アプリケーションがデータベースから切断したとき

関連パラメーター

入出力サーバーは、バックアップや復元などのユーティリティーを使って、 データベース・エージェントの代わりに事前取り出し入出力および非同期入出力を実行します。 このパラメーターは、 1 つのデータベースに置く入出力サーバーの数を指定します。 この数を超えた事前取り出しやユーティリティーの入出力が、 データベースに実行されることはありません。 入出力サーバーは、 それが開始した入出力操作が進行中である間は待機します。 事前取り出し以外の入出力は、 データベース・エージェントで直接スケジュールされないので、 num_ioservers の制限は受けません。

推奨事項: システム内の入出力装置をすべて完全に活用するには、 データベースがある物理装置の数より 1 つか 2 つ多い数を指定するのが一般的には最善の選択です。 各入出力サーバーのオーバーヘッドは最小限に抑えられ、 未使用の入出力サーバーはアイドル状態になるので、 追加の入出力サーバーを構成するようお勧めします。

詳細については、バッファー・プールへのデータの事前取り出し および 事前取り出しおよび並列入出力を行うための入出力サーバーの構成を参照してください。

索引分類フラグ (indexsort)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
Yes [ Yes; No ]

このパラメーターは、 索引の作成時に索引キーを分類するかどうかを示します。 特にクラスター率またはクラスター係数が低い索引の場合、 分類を最初に行うと索引作成のパフォーマンスは向上します。 作成時に索引を分類すると、 照会のパフォーマンスも向上することがあります。 パフォーマンスの向上に伴うコストは、 分類を行うのに必要なディスク・スペースが増えることです。 最初の段階で分類を行わずに索引を作成した場合と比べると、 必要なスペース量は 2 倍にも上ります。

推奨事項: ディスク・スペースが不足していない場合は、 省略時の設定値 ("Yes") を使用してください。 この分類で必要になるディスク・スペースは、 索引列に ORDER BY 文節を指定して表の索引列について SELECT を実行するのに必要なディスク・スペースとほぼ同じです。

対称マルチプロセッサー (SMP) 環境を持っているときにこのパラメーターに "No" を指定すると、 SMP 環境で使用できる多重プロセスは、索引作成時には使えません。

順次検出フラグ (seqdetect)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
Yes [ Yes; No ]

関連パラメーター
省略時事前取り出しサイズ (dft_prefetch_sz)

データベース・マネージャーは、入出力をモニターすることができます。 順次ページを読み取り中は、入出力事前取り出しを活動化することもできます。 このタイプの順次事前取り出しのことを、 順次検出 といいます。 データベース・マネージャーが順次検出を実行するかどうかは、 seqdetect 構成パラメーターを使って制御することができます。

このパラメーターを「No」に設定すると、たとえば、表分類、表走査、 またはリスト事前取り出しなどで事前取り出しが効果的であるとデータベース・マネージャーが判断したときだけ、 事前取り出しが行われます。

推奨事項: ほとんどの場合は、 このパラメーターには省略時値を使用してください。 順次検出をオフにするのは、 重大な照会パフォーマンスの問題が他の調整方法では訂正できない場合だけにしてください。

省略時事前取り出しサイズ (dft_prefetch_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
32 [ 0 〜 32 767 ]

OS/2 および Windows NT
16 [ 0 〜 32 767 ]

計測単位
ページ

関連パラメーター

表スペースを作成するときに、 オプションとして PREFETCHSIZE n を指定することができます。 n は、 事前取り出しを実行したときにデータベース・マネージャーが読み取るページ数を表しています。 CREATE TABLESPACE ステートメントで事前取り出しサイズを指定しないと、 このパラメーターの値がデータベース・マネージャーにより使用されます。

詳細については、バッファー・プールへのデータの事前取り出しを参照してください。

推奨事項: システム・モニター・ツールを使用すると、 システムが入出力を待っているときに CPU がアイドル状態になっているかどうかを判別することができます。 使用している表スペースの事前取り出しサイズが定義されていない場合には、 このパラメーターの値を大きくすると効果的なことがあります。

このパラメーターは、データベース全体について省略時値を設定するので、 データベースに含まれるすべての表スペースにとって適切な設定にはならない場合があります。 たとえば、値を 32 に設定すると、エクステント・サイズが 32 ページの表スペースには適切な設定でも、 エクステント・サイズが 25 ページの表スペースには適切でない可能性があります。 理想的なのは、表スペースごとに事前取り出しサイズを明示的に設定することです。

省略時のエクステント・サイズ (dft_extent_sz) で定義された表スペースの入出力を最小に抑えるには、 このパラメーターを、 dft_extent_sz パラメーター値の因数または倍数 (整数) に設定してください。 たとえば、dft_extent_sz パラメーターが 32 の場合、 dft_prefetch_sz は 16 (32 の因数) か 64 (32 の倍数) に設定することができます。 エクステント・サイズの倍数を事前取り出しサイズとして設定する場合、 次の条件が満たされると、データベース・マネージャーは入出力をパラレルに実行することがあります。

SMS コンテナーの省略時数 (numsegs)

構成タイプ
データベース

パラメーター・タイプ
情報

計測単位
カウンター

このパラメーターは、省略時の表スペースに作成されるコンテナーの数を示します。 ただし、SMS 表スペースにしか適用されません。 このパラメーターは、データベースを作成したときの情報を示します。 CREATE DATABASE コマンドで明示的に情報を指定したか、 暗示的に指定したかは関係ありません。 CREATE TABLESPACE ステートメントがこのパラメーターを使用することはありません

詳しくは、管理の手引き: 計画 にある『データベースの物理ディレクトリー』を参照してください。

表スペースの省略時エクステント・サイズ (dft_extent_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
32 [ 2 〜 256 ]

計測単位
ページ

関連パラメーター
省略時事前取り出しサイズ (dft_prefetch_sz)

表スペースを作成するときに、オプションとして EXTENTSIZE n を指定することができます。 n はエクステント・サイズを表しています。 CREATE TABLESPACE ステートメントでエクステント・サイズを指定しないと、 データベース・マネージャーはこのパラメーターの値を使用します。

詳しくは、管理の手引き: 計画 にある『表スペースの設計と選択』を参照してください。

推奨事項: 多くの場合、 表スペースの作成時点で、エクステント・サイズを明示的に指定できます。 このパラメーターの値を選択する前に、CREATE TABLESPACE ステートメントで、 どのようにエクステント・サイズを明示的に選択するかをあらかじめ理解しておく必要があります。 詳しくは、照会最適化に対する表スペースの影響を参照してください。

拡張記憶域メモリー・セグメント・サイズ (estore_seg_sz)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
16 000 [0 〜 1 048 575]

計測単位
ページ

関連パラメーター
拡張記憶域メモリー・セグメントの数 (num_estore_segs)

このパラメーターは、 データベース内の各拡張メモリー・セグメントのページ数を指定します。 この構成パラメーターを設定するときは、 プラットフォームごとに考慮すべき点が異なります。

推奨事項: このパラメーターが効力を持つのは、 拡張記憶域が使用可能で、 num_estore_segs パラメーターで指示されるように使用されるときです。 各拡張メモリー・セグメントで使用されるページ数を指定するときは、 num_estore_segs パラメーターの検討と修正を行って、 拡張メモリー・セグメント数についても考慮する必要があります。 拡張記憶域についての詳細は、 メモリーの拡張を参照してください。

拡張記憶域メモリー・セグメントの数 (num_estore_segs)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
0 [ 0 〜 214 7483 647 ]

関連パラメーター
拡張記憶域メモリー・セグメント・サイズ (estore_seg_sz)

このパラメーターは、 データベースで使用できる拡張記憶域メモリー・セグメントの数を指定します。

省略時値は、拡張記憶域メモリー・セグメントなしです。

推奨事項: このパラメーターは、 使用するプラットフォーム環境に最大アドレス空間よりも大きいメモリーがあり、 そのメモリーを使用したいときに、 拡張記憶域メモリー・セグメントを使用できるようにするためにだけ使用してください。 セグメント数を指定するときは、各セグメントのサイズについても考慮し、 estore_seg_sz パラメーターについて検討と修正を行う必要があります。

num_estore_segsestore_seg_sz の構成パラメーターを共に設定したときは、 CREATE/ALTER BUFFERPOOL ステートメントで、 どのバッファー・プールが拡張メモリーを使用するのかを指定する必要があります。 拡張記憶域についての詳細は、メモリーの拡張を参照してください。

エージェント

次のパラメーターは、並行して実行できるアプリケーションの数を制御し、 最適なパフォーマンスが得られるようにします。

活動アプリケーションの最大数 (maxappls)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
40 [ 1 〜 64 000 ]

OS/2 および Windows NT ローカル・クライアントおよびリモート・クライアントをもつデータベース・サーバー
20 [ 1 〜 64 000 ]

OS/2 および Windows NT ローカル・クライアントをもつデータベース・サーバー
10 [ 1 〜 64 000 ]

計測単位
カウンター

関連パラメーター

このパラメーターは、 データベースに並行接続 (ローカルおよびリモート) できるアプリケーションの最大数を指定します。 データベースに接続するアプリケーションごとに私用メモリーがいくらか割り振られるので、 並行アプリケーションの数を多くすると、使用されるメモリーも増えます。

このパラメーターには、接続されるアプリケーションの合計数に、 2 フェーズ・コミットまたはロールバックの完了を並行して処理する同じアプリケーションの数を加えた数値、 またはそれよりも大きい数値を指定しなければなりません。 次に、その合計数に、 生じるかもしれない未確定トランザクションの予想数を加えます。 未確定トランザクションの詳細については、 管理の手引き: 計画 の『2 フェーズ・コミット時の問題を回復する』を参照してください。

maxappls に達しているのに、 アプリケーションがデータベースに接続しようとすると、エラーがアプリケーションに戻され、 最大数のアプリケーションがデータベースに接続していることを示します。

データ・リンク・マネージャーを使用するアプリケーションが多くなる場合は、 maxappls の値を増やす必要があります。 以下の式を使用して、必要な値を計算してください。

   <maxappls> = 5 * (ノードの数) + (データ・リンク・マネージャーを使用する
                      活動アプリケーションのピーク数)

データ・リンク・マネージャーでサポートされている最大値は 2 000 です。

区分データベース環境では、この値は、 データベース区画で同時に活動状態にできるアプリケーションの最大数です。 このパラメーターは、そのデータベース区画における活動状態アプリケーションの数を、 データベース区画サーバーに制限します。これは、 このサーバーがそのアプリケーションの調整プログラム・ノードであるか否かには関係ありません。 区分データベース環境のカタログ・ノードには、 他のタイプの環境の場合よりも大きい maxappls 値が必要です。 これは、区分データベース環境では、各アプリケーションでカタログ・ノードへの接続が必要になるためです。

推奨事項: maxlocks パラメーターを小さくしたり locklist パラメーターを大きくしないでこのパラメーターの値を大きくすると、 アプリケーションの限界ではなくデータベースのロック制限 (locklist) に達してしまうため、 ロック・エスカレーション問題が起こることがあります。

アプリケーションの最大数は、 ある程度 maxagents によっても制御されています。 アプリケーションは、利用可能な接続 (maxappls) および利用可能なエージェント (maxagents) があるときに限り、 データベースに接続できます。 さらに、アプリケーションの最大数は、 max_coordagents 構成パラメーターによっても制御されます。 すでに max_coordagents に到達している場合は、 新しいアプリケーション (すなわち調整エージェント) を開始できないからです。

活動アプリケーションの平均数 (avg_appls)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]
1 [ 1 〜 maxappls ]

計測単位
カウンター

関連パラメーター

このパラメーターは、SQL 最適化プログラムが、 選択されたアクセス・プランの実行時に利用可能になるバッファー・プール量を見積もるときに使用します。 このパラメーターを大きくすると、最適化プログラムは、 バッファー・プール使用法をより控えめに見積もった照会アクセス・プランを選択するようになります。

推奨事項: 複数ユーザー環境で DB2 を実行する場合、 特に複雑な照会や大きなバッファー・プールを使用する場合は、 複数の照会ユーザーがシステムを使用しているので、 バッファー・プールの使用可能度を控えめに見積もるように SQL 最適化プログラムに指示することができます。

このパラメーターを設定するときは、 データベースを通常どおり使用する多量照会アプリケーションの数を見積もる必要があります。 この見積もりには、 簡単な OLTP アプリケーションは含めないでください。 見積もりが容易でない場合は、 次の数を乗算することができます。

最適化プログラムに影響する他の構成パラメーターを調整するときは、 このパラメーターも多少調整してください。 そうすると、パスを選択するときの差を最小にすることができます。

このパラメーターを変更してから、 アプリケーションの再バインドを考慮する必要があります (REBIND PACKAGE コマンドを使用)。

アプリケーションごとにオープンするデータベース・ファイルの最大数 (maxfilop)

構成タイプ
データベース

パラメーター・タイプ
構成可能

省略時値[範囲]

UNIX
64 [ 2 〜 1950 ]

OS/2 および Windows NT
64 [ 2 〜 32 768 ]

計測単位
カウンター

関連パラメーター

このパラメーターは、データベース・エージェントごとにオープンする、 ファイル・ハンドルの最大数を指定します。 あるファイルを開いたためにこの値を超えてしまった場合、 このエージェントが使用しているファイルの一部が閉じられます。 maxfilop が小さすぎると、 限度を超えないためにファイルを開閉するさいのオーバーヘッドが過度になり、 パフォーマンスが低下することがあります。

SMS 表スペースと DMS 表スペース・ファイル・コンテナーは両方とも、 データベース・マネージャーとオペレーティング・システムの間の対話でファイルとして扱われるため、 ファイル・ハンドルが必要になります。 DMS ファイル表スペースで使用されるコンテナーの数と比較すると、 SMS 表スペースの方が一般的に多くのファイルを使用します。 したがって、SMS 表スペースを使用している場合は、 DMS ファイル表スペースで必要な数より大きい値をこのパラメーターに指定する必要があります。

また、エージェントあたりのハンドル数を特定の数に制限して、 データベース・マネージャーで使用するファイル・ハンドルの全合計がオペレーティング・システムの制限を超えないようにするために、 このパラメーターを使うこともできます。 実際の数は、並行して実行しているエージェントの数によって異なります。

アプリケーションごとにオープンするファイルの最大合計数 (maxtotfilop)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
16 000 [ 100 〜 32 768 ]

計測単位
カウンター

関連パラメーター
アプリケーションごとにオープンするデータベース・ファイルの最大数 (maxfilop)

このパラメーターは、 1 つのデータベース・マネージャー・インスタンスで実行中のエージェントおよび他のスレッドでオープンできるファイルの最大数を定義します。 この値を超えた数のファイルをオープンしようとすると、 アプリケーションにエラーが戻されます。
注:このパラメーターは UNIX ベースのプラットフォームには適用されません。

推奨事項: このパラメーターを設定するときは、 データベース・マネージャー・インスタンスの各データベースで使用できるファイル・ハンドルの数を考慮に入れてください。 このパラメーターの上限は、次の方法で見積もることができます。

  1. インスタンスのデータベースごとにオープンできるファイル・ハンドルの最大数を計算します。 次の式を使用します。
        maxappls * maxfilop
    
  2. 上の式の結果を合計し、 その数がパラメーターの最大数を超えないかどうか検査します。

新しいデータベースを作成する場合は、このパラメーターの値も再評価してください。

システムで使用するファイル・ハンドルの合計が、 システムで許可されている最大数を超えていないかどうかも検査してください。 次の式を使用します。

     (すべてのインスタンスまたはマシンに関する maxtotfilop の合計)
   + (他のアプリケーションで必要なファイル・ハンドルの見積数)
   <= 65535

エージェントの優先順位 (agentpri)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]

AIX
-1 [ 41 〜 125 ]

その他の UNIX
-1 [ 41 〜 128 ]

Windows NT
-1 [ 0 - 6 ]

OS/2
-1 [ 200 〜 231; 300 〜 331; 400 〜 431 ]

このパラメーターは、オペレーティング・システムのスケジューラーが、 すべてのエージェント、 およびその他のデータベース・マネージャー・インスタンス・プロセスやスレッドに指定した優先順位を制御します。 区分データベース環境では、調整エージェントと並列エージェントの両方、 並列システム制御装置、および FCM デーモンも含まれます。 この優先順位により、DB2 プロセス、エージェントおよびスレッドに与えられる CPU 時間が、 このマシンで実行される他のプロセスやスレッドとの関連で決まります。 パラメーターを -1 に設定すると、それは特別なアクションが何も実行されないこと、 および通常オペレーティング・システムがすべてのプロセスとスレッドをスケジュールする方法でデータベース・マネージャーがスケジュールされることを示します。 このパラメーターに -1 以外の値を設定すると、データベース・マネージャーは、 そのパラメーター値に設定された静的優先順位でプロセスとスレッドを作成します。 このように、このパラメーターを使うと、 ユーザーのマシンで実行するデータベース・マネージャー・プロセスおよびスレッドの優先順位を制御することができます。

このパラメーターを使用してデータベース・マネージャーのスループットを上げることができます。 このパラメーターに設定する値は、データベース・マネージャーを実行しているオペレーティング・システムによって異なります。 たとえば、UNIX ベースの環境では、数値が小さいと優先順位が高くなります。 このパラメーターを 41 と 125 の間の値に設定すると、データベース・マネージャーは、 UNIX 静的優先順位としてこのパラメーターの値が設定されたエージェントを作成します。 これは UNIX ベースの環境では重要です。 低い数値のものはデータベース・マネージャーに対する高い優先順位が得られる一方、 他のプロセス (アプリケーションおよびユーザーも含む) は十分な CPU 時間を獲得できないために遅れる可能性があるからです。 したがって、マシンに期待される他の活動とのバランスを考えて、 このパラメーターを設定する必要があります。

OS/2 環境では、より大きい数値を設定するとより高い優先順位が得られます。

推奨事項: 最初は省略時値を使用してください。 この値を使用すると、他のユーザー / アプリケーションとデータベース・マネージャー・スループットとの間で応答時間をちょうどよい状態に調整することができます。

データベースのパフォーマンスを考慮するときは、ベンチマーク技法を使って、 このパラメーターの最適な設定を判別することができます。 特に CPU の使用率が非常に高い場合、 データベース・マネージャー優先順位を高くすると他のユーザー処理のパフォーマンスが重大な影響を受けることがあるので、 十分注意を払ってください。 データベース・マネージャー・プロセスおよびスレッドの優先順位を高くすると、パフォーマンスは大きく向上します。
注:このパラメーターを UNIX ベースのプラットフォームで非省略時値に設定すると、 管理プログラムを使ってエージェントの優先順位を変更できません。

エージェントの最大数 (maxagents)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
200 [ 1 〜 64 000 ]

400 [ 1 〜 64 000 ] (ローカル・クライアントおよびリモート・クライアントをもつ区分化データベース・サーバーの場合)

10 [ 1 〜 64 000 ] (ローカル・クライアントをもつサテライト・データベース・サーバー の場合)

計測単位
カウンター

関連パラメーター

このパラメーターは、随時アプリケーションの要求を受け付けることができる、 利用可能なデータベース・マネージャー・エージェントの最大数を示します。 エージェントは調整エージェントまたはサブエージェントのいずれも含まれます。 調整エージェントの数を制限したい場合は、 max_coordagents パラメーターを使用してください。

メモリーは、エージェントが増えるたびに追加する必要があるので、 このパラメーターは、メモリーの制約がある環境でデータベース・マネージャーの使用する合計メモリー量を制限するのに役立ちます。

推奨事項: maxagents の値は、 並行アクセスできる個々のデータベースに設定された maxappls の値の合計数以上に設定してください。 numdb パラメーターより大きい場合は、 maxappls の最大値と numdb の積を用いるのが最も安全です。

エージェントを追加するたびに、データベース・マネージャーの開始時に割り振られたリソースのオーバーヘッドが多少生じます。

並行エージェントの最大数 (maxcagents)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
-1 (max_coordagents) [-1; 1 〜 max_coordagents ]

計測単位
カウンター

関連パラメーター

並行してデータベース・マネージャー・トランザクションを実行できるデータベース・マネージャー調整エージェントの最大数を設定します。 このパラメーターは、 同時に実行されるアプリケーション活動が多いときのシステムの負荷を制御するのに使用します。 たとえば、 多数の接続を必要とするがそれらの接続を処理するためのメモリー量が限られているようなシステムがあります。 同時に実行される活動が多い状態が続くとオペレーティング・システムで過度のページングが生じる可能性があるような、 このような環境では、このパラメーターを調整することは効果的です。

このパラメーターにより、 データベースに接続できるアプリケーションの数が制限されることはありません。 データベース・マネージャーで並行処理できるデータベース・マネージャー・エージェントの数だけが制限されます。したがって、 処理がピークのときのシステム・リソースの使用法を制限することができます。

値 -1 は、この制限が max_coordagents であることを示します。

推奨事項: ほとんどの場合は、 このパラメーターの省略時値はそのまま使用できます。 アプリケーションの並行性が原因で問題が生じている場合は、 ベンチマーク・テストを使ってこのパラメーターを調整し、 パフォーマンスを最適化することができます。

調整エージェントの最大数 (max_coordagents)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
-1 (maxagentsnum_initagents)

[-1, 0 〜 maxagents]

区分データベース環境および intra_parallel が "Yes" に設定されている環境では、 省略時値は maxagents - num_initagents です。 その他の環境では、省略時値は maxagents です。 このため、区分データベース環境以外では、 システムが区画内並行処理用に構成されていなければ、 max_coordagents は常に maxagents に同じです。

区分データベース環境を持たず、 したがって intra_parallel パラメーターを使用可能にしない場合は、 max_coordagentsmaxagents に同じでなければなりません。

関連パラメーター

このパラメーターは、 ある一時点に区分データベース環境または非区分データベース環境のサーバーに存在できる調整エージェントの最大数を決めます。

データベースに接続される、 またはインスタンスに接続される各ローカルまたはリモートのアプリケーションごとに 1 つの調整エージェントが獲得されます。 インスタンス接続を必要とする要求としては、 CREATE DATABASE、DROP DATABASE および データベース・システム・モニター・コマンドがあります。

論理エージェントの最大数 (max_logicagents)

構成タイプ
データベース・マネージャー

パラメーター・タイプ
構成可能

省略時値[範囲]
-1 (max_coordagents) [ -1; max_coordagents 〜 64 000 ]

このパラメーターは、 インスタンスに接続できるアプリケーションの最大数を制御します。 通常、 アプリケーションごとに調整エージェントが割り当てられます。 エージェントは、 アプリケーションとデータベースの間の操作を手助けするものです。 このパラメーターの省略時値を使用する場合、 コンセントレーター機能は非活動状態になります。 そのため、 各エージェント・プロセスは自らの私用メモリーを使って操作を行いますが、 データベース・マネージャーおよびデータベース大域リソース (バッファー・プールなど) は他のエージェントと共用します。 このパラメーターに、省略時値よりも大きい値を設定すると、 コンセントレーター機能が活動化状態になります。 コンセントレーターの目的は、 DB2 コネクト・ゲートウェイが 10 000 個を超えるクライアント接続を処理できる程度にまで、 クライアント・アプリケーションごとのサーバー・リソースを減らすことです。

値 -1 は、 この制限が max_coordagents であることを示します。

エージェント・プール・サイズ (num_poolagents)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
-1 [-1, 0 〜 maxagents]

省略時値を使用すると、 非区分データベースとローカル・クライアントを持つサーバーのための値は、 maxagents/50 と max_querydegree のいずれか大きいほうになります。

省略時値を使用すると、 非区分データベースとローカルおよびリモートのクライアントを持つサーバーのための値は、 maxagents/50 x max_querydegree または maxagents - max_coordagents のいずれか大きいほうになります。

省略時値を使用すると、データベース区画サーバーのための値は、 maxagents/10 x max_querydegree または maxagents - max_coordagents のいずれか大きいほうになります。

関連パラメーター

このパラメーターは、 エージェント・プールをどこまで大きくしたいかの指針です (これは DB2 バージョン 2 で使用されていた max_idleagents パラメーターに置き換わるものです)。

エージェント・プールにはサブエージェントまたはアイドル・エージェントが入ります。 アイドル・エージェントは、 並列サブエージェントまたは調整エージェントとして使用することができます。 このパラメーターの値で指示された数よりも多いエージェントが作成されると、 それらのエージェントは、現行要求の実行の終了時にプールには戻されずに、 終了します。

このパラメーターの値が 0 であると、エージェントは必要に応じて作成され、 現行要求の実行が終了すると、エージェントも終了します。 この値が maxagents の場合、プールが関連サブエージェントでいっぱいになると、 新規の調整エージェントが作成できないため、サーバーは調整プログラム・ノードとしては使用できません。

推奨事項: 同時に接続するアプリケーションが少ない意思決定支援環境を実行する場合は、 エージェント・プールにアイドル・エージェントが多数あるような状態にならないように num_poolagents を小さい値に設定してください。

多数のアプリケーションが並行に接続されているトランザクション処理環境を実行する場合は、 エージェントの作成と終了を頻繁に行うためのコストがかかることがないように、 num_poolagents の値は大きくしてください。

プール内の初期エージェント数 (num_initagents)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
0 [0 〜 num_poolagents]

関連パラメーター

このパラメーターは、 DB2START 時にエージェント・プールに作成されるアイドル・エージェントの初期数を決めます。

データベース・アプリケーション・リモート・インターフェース (DARI)

次のパラメーターは、 データベース・アプリケーション・リモート・インターフェース (DARI) アプリケーションを制御します。

注:用語 DARI は、ストアード・プロシージャーのことです。

DARI プロセス保持標識 (keepdari)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
Yes [ Yes; No ]

関連パラメーター
DARI プロセスの最大数 (maxdari)

このパラメーターは、 DARI 呼び出しが完了した後、 DARI プロセスを保持するか否かを指示します。 DARI プロセスは、 ユーザー作成の DARI コードをデータベース・マネージャー・エージェント・プロセスと分離するために、 別個のシステム・エンティティーとして作成されます。 このパラメーターは、データベース・サーバーだけに適用されます。

keepdarino に設定すると、 DARI 呼び出しのたびに新しい DARI プロセスが作成され、破棄されます。 keepdariyes に設定すると、 以後の DARI 呼び出しでも DARI プロセスが再利用されます。 データベース・マネージャーが停止すると、未解決な DARI プロセスはすべて終了します。

このパラメーターを yes に設定すると、DARI プロセスを活動化するたびに、 追加のシステム・リソースがデータベース・マネージャーのために消費されます。 その数の最大値は、maxdari パラメーターの値です。 このような状態は、 後続の DARI 呼び出しを処理するのに利用可能な DARI プロセスが存在しない場合に生じます。 maxdari が 0 に設定されていると、 このパラメーターは無視されます。

推奨事項: 非 DARI 要求の数に比べて DARI 要求の数が多い環境で、 システム・リソースが制約されていない場合には、 このパラメーターは yes に設定することができます。 呼び出しの処理には既存の DARI プロセスが使用されるので、 上記のように設定すると、 DARI プロセスの初期作成時のオーバーヘッドを避けることができます。 結果として DARI のパフォーマンスは向上します。

たとえば、OLTP 貸借取引トランザクション・アプリケーションの場合、 各トランザクションを実行するコードをストアード・プロシージャーに入れて、 そのプロシージャーを DARI プロセスで実行することができます。 このアプリケーションの場合、 主な作業負荷は DARI プロセスで実行されます。 このパラメーターを no に設定すると、 トランザクションごとに新規の DARI プロセスが作成されるため、 オーバーヘッドが生じ、 結果としてパフォーマンスは著しく低下します。 このパラメーターを yes に設定すると、 各トランザクションは既存の DARI プロセスを使用しようとするので、 オーバーヘッドは生じません。

DARI プロセスの最大数 (maxdari)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
-1 (max_coordagents) [ -1; 0 〜 max_coordagents ]

計測単位
カウンター

関連パラメーター

このパラメーターは、 データベース・サーバーに入れられる DARI プロセスの最大数を示します。 この制限に達すると、 新規の DARI 要求を呼び出すことができなくなることがあります。 このパラメーターは、データベース・サーバーだけに適用されます。

1 つの調整エージェントには 1 つの DARI プロセスしか活動できません。 したがって、DARI プロセスの最大数は調整エージェントの最大数 (max_coordagents) によって決まります。

推奨事項: データベース・マネージャーで DARI 機能を使用できる環境では、このパラメーターを使って、 任意の一時点でデータベース・マネージャー内で DARI 呼び出しを処理できるように、 適切な数の DARI プロセスを使用可能にしておくことができます。

このパラメーターを -1 に設定すると、 DARI プロセスの最大数は、max_coordagents パラメーターに設定された値と同じになります。

不適切な量のシステム・リソースが DARI プロセスに与えられているためデータベース・マネージャーのパフォーマンスが影響を受けており、 使用中の環境で省略時値を使用するのが適切ではないと判断した場合、次の式を用いて、 パラメーターを調整する際の開始点を決定することができます。

    maxdari = 同時に DARI 呼び出しを行うことのできるアプリケーションの数

keepdariyes に設定されていると、 作成される個々の DARI プロセスは、DARI 呼び出しが処理されてエージェントに戻された後も引き続き存在し、 システム・リソースを使用し続けます。

使用中の環境にさまざまな制限があるため、処理リソースを DARI に関連付けることができない場合は、 このパラメーターをゼロ (0) に設定して DARI を使用不能にすることができます。

JVM による DARI プロセスの初期化 (initdari_jvm)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
No [ Yes; No ]

関連パラメーター

このパラメーターは、 それぞれの分離 DARI プロセスが始動時に Java 仮想マシン (JVM) をロードするかどうかを示します。 このパラメーターにより、 分離 Java ストアード・プロシージャーの最初の起動時間は減少します (特に、 num_initdaris パラメーターと一緒に使用した場合)。 Java 以外の分離ストアード・プロシージャーの場合、 JVM は必要ないので、 このパラメーターによって初期ロード時間が増加する可能性があります。

プール内の分離 DARI プロセスの初期数 (num_initdaris)

構成タイプ
データベース・マネージャー

適用範囲

パラメーター・タイプ
構成可能

省略時値[範囲]
0 [ 0 〜 maxdari ]

関連パラメーター

このパラメーターは、 DB2START 時に DARI プールに作成される分離 DARI プロセスの初期数を示します。 このパラメーターを設定すると、 分離ストアード・プロシージャーの最初の起動時間が減少します。 keepdari が指定されていないと、 このパラメーターは無視されます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]