Hitachi

JP1 Version 11 JP1/Performance Management - Agent Option for IBM DB2


DB2 Configuration(PD_DCFE)

〈このページの構成〉

機能

DB2構成パラメーター情報を格納しています。

デフォルト値および変更できる値

項目

デフォルト値

設定可否

Collection Interval

3600

Collection Offset

0

Log

No

LOGIF

空白

Over 10 Sec Collection Time

No

×

ODBCキーフィールド

なし

ライフタイム

データベースの作成から削除まで。

レコードサイズ

フィールド

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

App Ctl Heap SZ

(APP_CTL_HEAP_SZ)

アプリケーション・コントロール・ヒープ・サイズ。ページ(4キロバイト)単位。

word

No

すべて

SQLF_DBTN_APP_CTL_HEAP

_SZ

詳細説明:

パーティション・データベースの場合,およびパーティション内並列処理が使用できる(intra_parallel=ON)の非パーティション・データベースの場合は,このパラメーターは,アプリケーション用として割り振られる共有メモリー領域の平均サイズを指定します。パーティション内並列処理が使用不可(intra_parallel=OFF)の非パーティション・データベースの場合は,これはヒープとして割り振られる最大専用メモリー・サイズです。それぞれのパーティションごとに1つの接続に1つずつアプリケーション・コントロール・ヒープがあります。

アプリケーション・コントロール・ヒープが必要なのは,主として,同一要求のために作動するエージェント間で情報を共用するためです。このヒープの使用量が最小になるのは,非パーティション・データベースで,1に等しい並列処理の度合いで照会を実行しているときです。

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

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Appgroup Mem SZ

(APPGROUP_MEM_SZ)

アプリケーション・グループ・メモリー・セットの最大サイズ。ページ(4キロバイト)単位。

ulong

No

すべて

SQLF_DBTN_APPGROUP_MEM

_SZ

詳細説明:

このパラメーターでは,アプリケーション・グループ共有メモリー・セグメントのサイズを決定します。同じアプリケーションを使用するエージェント間で共有する必要がある情報は,アプリケーション・グループ共有メモリー・セグメントに保管されます。

パーティション・データベース,またはパーティション内並列処理が使用できるか,集線装置が使用できる非パーティション・データベースでは,複数のアプリケーションが1つのアプリケーション・グループを共有します。アプリケーション・グループ共有メモリー・セグメントが1つ,アプリケーション・グループに割り振られます。アプリケーション・グループ共有メモリー・セグメント内では,各アプリケーションにそれぞれ固有のアプリケーション・コントロール・ヒープがあり,すべてのアプリケーションで1つのアプリケーション・グループ共有ヒープを共有します。

1つのアプリケーション・グループ内のアプリケーションの数は,次のようにして計算されます。

appgroup_mem_sz/app_ctl_heap_sz

アプリケーション・グループ共有ヒープ・サイズは,次のようにして計算されます。

appgroup_mem_sz*groupheap_rate/100

各アプリケーション・コントロール・ヒープのサイズは,次のようにして計算されます。

app_ctl_heap_sz*(100-groupheap_rate)/100

監視対象のDB2がV9.5以降の場合,非推奨項目となり正しい値を収集できません。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

ApplheapSZ

(APPLHEAPSZ)

アプリケーション・ヒープ・サイズ。ページ(4キロバイト)単位。

word

No

すべて

SQLF_DBTN_APPLHEAPSZ

詳細説明:

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

エージェントまたはサブエージェントがアプリケーション用に初期化されると,ヒープが割り振られます。割り振られる量は,エージェントまたはサブエージェントに指定された要求を処理するのに最低限必要な量です。エージェントまたはサブエージェントが,大きなSQLステートメントを処理するためにさらにヒープ・スペースを要求した場合は,データベース・マネージャーが必要に応じて,このパラメーターで指定された最大値までメモリーを割り振ります。

注:

パーティションのあるデータベース環境では,アプリケーション・コントロール・ヒープ(app_ctl_heap_sz)が,エージェントとサブエージェントのSQLステートメントの実行セクションでのコピーを保管するのに使用されます。ただし,ほかのすべての環境でエージェントを実行するときは,SMPサブエージェントは,applheapszを使用します。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Catalogcache SZ

(CATALOGCACHE_SZ)

カタログ・キャッシュ・サイズ。ページ(4キロバイト)単位。

long

No

すべて

SQLF_DBTN_CATALOGCACHE

_SZ

詳細説明:

このパラメーターは,データベース共有メモリーから割り振られ,システム・カタログ情報をキャッシュに入れる場合に使用されます。パーティション・データベース・システムでは,それぞれのデータベース・パーティションごとにカタログ・キャッシュが1つずつあります。

個々のパーティションでカタログ情報をキャッシュに入れると,データベース・マネージャーは,以前検索された情報を入手するためにシステム・カタログまたはパーティション・データベース環境でのカタログ・ノード,またはその両方にアクセスする必要がなくなるので,その内部オーバーヘッドを低減できます。カタログ・キャッシュは,次の情報を保管するのに使用されます。

  • SYSTABLES情報(パック記述子を含む)

  • SYSDBAUTH情報およびルーチンの実行特権を含む,許可情報

  • SYSROUTINES情報

カタログ・キャッシュを使用することによって,次の操作の総合的なパフォーマンスが向上します。

  • パッケージのバインドおよびSQLステートメントのコンパイル

  • データベース・レベル特権のチェックを伴う操作

  • ルーチンの実行特権のチェックを伴う操作

パーティション・データベース環境で非カタログ・ノードに接続されるアプリケーションサーバまたはパーティション・データベース環境でデフォルト(-1)であれば,ページ割り振りの計算に使用される値は,maxappls構成パラメーターに指定されている値の4倍になります。これに対する例外が生じるのは,maxapplsの4倍が8より小さい場合です。この状態では,デフォルト値-1で,catalogcache_szは8に設定されます。

推奨:

デフォルト値で開始し,データベース・システム・モニターを使用して調整してください。このパラメーターを調整するときは,カタログ・キャッシュ用として予約されている余分のメモリーについて,例えば,バッファー・プールやパッケージ・キャッシュなどといった別の目的に割り振った方が,その有効性が増すかどうか考慮する必要があります。

このパラメーターの調整が特に重要なのは,ワークロードに多くのSQLコンパイルが短期間伴い,その後はSQLコンパイルがほとんどまたはまったくない場合です。キャッシュが大き過ぎる場合は,使用されなくなった情報のコピーの保留にメモリーが浪費されるおそれがあります。

パーティション・データベース環境では,非カタログ・ノードで必要とされるカタログ情報は,必ず最初にカタログ・ノードでキャッシュに入れられるので,カタログ・ノードのcatalogcache_szは,設定値を大きくする必要があるかどうか考慮してください。

cat_cache_lookups(カタログ・キャッシュ・ルックアップ),cat_cache_inserts(カタログ・キャッシュ挿入),cat_cache_overflows(カタログ・キャッシュ・オーバーフロー),およびcat_cache_size_top(カタログ・キャッシュ最高水準点)モニター・エレメントは,この構成パラメーターを調整する必要があるかどうか判別する場合に役立ちます。

注:

カタログ・キャッシュは,パーティション・データベース環境のすべてのノードにあります。それぞれのノードごとにローカル・データベース構成ファイルがあるので,それぞれのノードのcatalogcache_sz値によって,ローカル・カタログ・キャッシュのサイズが定義されます。キャッシングが効率的に行われ,オーバーフローが発生しないようにするために,それぞれのノードでcatalogcache_sz値を明示的に設定し,非カタログ・ノードのcatalogcache_szをカタログ・ノードの値よりも小さい値に設定できるおそれを考慮する必要があります。非カタログ・ノードでキャッシュに入れる必要のある情報は,カタログ・ノードのキャッシュから検索されるということを念頭に置いてください。したがって,非カタログ・ノードのカタログ・キャッシュは,カタログ・ノードのカタログ・キャッシュにある情報のサブセットのようなものです。

一般的に,キャッシュ・スペースが多く必要になるのは,作業単位に幾つもの動的SQLステートメントが含まれる場合,または多数の静的SQLステートメントが含まれるパッケージをバインドする場合です。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Chngpgs Thresh

(CHNGPGS_THRESH)

変更済みページ数しきい値。

word

No

すべて

SQLF_DBTN_CHNGPGS_THRESH

詳細説明:

このパラメーターを使用すると,非同期ページ・クリーナーが現在アクティブでない場合に,非同期ページ・クリーナーが始動する変更済みページ数のレベル(パーセント)を指定できます。ページ・クリーナーを始動すると,ディスクに書き込むページのリストが作成されます。これらのページのディスクへの書き込みが完了すると,ページ・クリーナーは再度非アクティブになり,次のトリガーの開始を待ちます。

読み取り専用(例えば,照会)環境では,このようなページ・クリーナーは使用されません。

推奨:

更新トランザクション・ワークロードが大きいデータベースの場合は,パラメーター値をデフォルト値以下に設定すれば,一般的には,バッファー・プール内に十分なクリーン・ページを確保できます。データベースに非常に大きな表が少数しかない場合は,パーセンテージをデフォルトよりも大きくすると,パフォーマンスが上がります。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Database Memory

(DATABASE_MEMORY)

データベース共有メモリー・サイズ。ページ(4キロバイト)単位。

ulong

No

すべて

SQLF_DBTN_DATABASE

_MEMORY

詳細説明:

このパラメーターは,特定のデータベース用として予約されている共有メモリーの最少量をコントロールします。このパラメーターを使用すると,データベース管理者はそれぞれのデータベースごとに,共有メモリーの最少量を指定できます。データベース・メモリーには,データベース・マネージャー共有メモリーやアプリケーション・グループ・メモリーは含まれません。

このパラメーターの管理を単純化するために,AUTOMATIC設定によって,必要なメモリーの量の計算,およびデータベース活動化時点でのその割り振りを,DB2に指示します。64ビットAIXでは,AUTOMATIC値によって,DB2は,バッファー・プールが増大したときや,制御ブロック用として追加のメモリーが必要になったときは,必要に応じてそのメモリー使用量を増やせます。

推奨:

この値は,通常,AUTOMATICのままになっています。ただし,将来の拡張に備えて追加のメモリーを予約するのに使用できます。例えば,追加のメモリーは,新規バッファー・プールを作成する場合や,既存のバッファー・プールのサイズを大きくする場合に使用できます。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Dbheap

(DBHEAP)

データベース・ヒープ。ページ(4キロバイト)単位。

ulong

No

すべて

SQLF_DBTN_DBHEAP

詳細説明:

データベースごとに1つのデータベース・ヒープがあり,データベース・マネージャーは,データベースに接続されているすべてのアプリケーションの代わりに,データベース・ヒープを使用します。これには表,索引,表スペース,およびバッファー・プールの制御ブロック情報が含まれます。また,イベント・モニター・バッファー,ログ・バッファー(logbufsz),およびユーティリティーによって使用される一時メモリー用のスペースも含まれます。したがって,ヒープのサイズは多数の変数によって決まることになります。制御ブロック情報は,すべてのアプリケーションがデータベースから切断されるまで,ヒープ内に保持されます。

データベース・マネージャーが始動のために取得する必要がある最少量は,最初の接続時に割り振られます。データ域は,dbheapによって指定されている最大値を上限として,必要に応じて拡張されます。

データベース・システム・モニターを使用すると,db_heap_top(割り振られる最大データベース・ヒープ)エレメントを使用して,データベース・ヒープ用として使用されたメモリーの最大量を追跡できます。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Dft Prefetch SZ

(DFT_PREFETCH_SZ)

デフォルトのプリフェッチ・サイズ。ページ(4キロバイト)単位。

short

No

すべて

SQLF_DBTN_DFT_PREFETCH

_SZ

詳細説明:

表スペースの作成時に,オプションでPREFETCHSIZEnを指定できます(nは,プリフェッチが行なわれる場合に,データベース・マネージャーが読み取るページ数です)。CREATETABLESPACEステートメントでプリフェッチ・サイズを指定しないと,データベース・マネージャーはこのパラメーターで与えられた値を使用します。

推奨:

システム・モニター・ツールを使用して,システムが入出力を待機しているときにCPUがアイドルになっているかどうかを判別できます。このパラメーターの値を増やすと,使用される表スペースのプリフェッチ・サイズが定義されていない場合に役立ちます。

このパラメーターは,データベース全体にデフォルト値を適用しますが,データベース内のすべての表スペースに適しているとは限りません。例えば,値32はエクステント・サイズが32ページの表スペースには適していますが,エクステント・サイズが25ページの表スペースには適していません。いちばんよい方法は,それぞれの表スペースにプリフェッチ・サイズを明示的に設定することです。

デフォルトの表スペース・エクステント・サイズ(dft_extent_sz)で定義された表スペースの入出力を最小化するには,このパラメーターをdft_extent_szパラメーターの値の因数または倍数として指定してください。例えば,dft_extent_szパラメーターが32の場合は,dft_prefetch_szを16(32の因数)または64(32の倍数)に設定します。プリフェッチ・サイズがエクステント・サイズの倍数である場合は,次の条件が満たされていればデータベース・マネージャーは入出力を並行して行うことができます。

  • プリフェッチ中のエクステントが異なる物理装置上にある

  • 複数の入出力サーバが構成されている(num_ioservers)

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Interval

(INTERVAL)

情報が収集される時間。秒単位。

ulong

No

すべて

RECORD_TIME - CURRENT

_SYSTEM_BOOT_TIME

詳細説明:

特になし。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Locklist

(LOCKLIST)

ロック・リスト用最大ストレージ。ページ(4キロバイト)単位。

ulong

No

すべて

SQLF_DBTN_LOCKLIST

詳細説明:

このパラメーターは,ロック・リストに割り振られているストレージ量を示します。データベースごとに1つのロック・リストがあり,ロック・リストには,データベースに同時に接続しているすべてのアプリケーションが保持しているロックが含まれています。ロックは,複数のアプリケーションがデータベース内にあるデータにアクセスするのをコントロールするために,データベース・マネージャーが使用するメカニズムです。行と表の両方がロックされます。データベース・マネージャーは内部使用のロックを獲得することもできます。

このパラメーターはオンラインで変更できますが,オンラインでは値を大きくすることができるだけで,値を小さくすることはできません。locklistの値を小さくしたい場合は,データベースを再活動化する必要があります。

32ビットのプラットフォームの場合は,それぞれのロックには,そのオブジェクトでほかのロックが保持されているかどうかによって,ロック・リストの36バイトまたは72バイトが必要です。

ほかにロックが保留されていないオブジェクトのロックを保留するには,72バイトが必要です。

既存のロックが保持されているオブジェクトのロックを記録するには,36バイトが必要です。

64ビットのプラットフォームの場合は,それぞれのロックには,そのオブジェクトでほかのロックが保持されているかどうかによって,ロック・リストの56バイトまたは112バイトが必要です。

ほかにロックが保留されていないオブジェクトのロックを保留するには,112バイトが必要です。

既存のロックが保持されているオブジェクトのロックを記録するには,56バイトが必要です。

1つのアプリケーションが使用するロック・リストのパーセント(%)がmaxlocksに達すると,データベース・マネージャーは,そのアプリケーションが保持するロックに対して,行から表にロック・エスカレーションをします。エスカレーション処理そのものにはそれほど時間は掛かりませんが,(個別の行に対するロックに対して)表全体のロックは並列性を減少させ,影響を受けた表に対する後続のアクセスのために,データベース・パフォーマンス全体が低下するおそれがあります。推奨されるロック・リスト・サイズのコントロール方法は,次のとおりです。

  1. ロックを解放するために頻繁にCOMMITを実行します。

  2. 多くの更新を実行するときには,(SQLLOCKTABLEステートメントを使用して)更新前に表全体をロックします。これは1つのロックだけを使用し,ほかのロックが更新に干渉しないようにしますが,データの並列性は減少します。

    また,ALTERTABLEステートメントのLOCKSIZEオプションを使用して,特定の表のロック方法をコントロールすることもできます。

    反復できる読み取り分離レベルを使用すると,自動的に表がロックされる場合があります。

保持された共有ロック数の減少ができる場合は,カーソル固定分離レベルを使用します。アプリケーション保全性要件と折り合わない場合は,ロックの量をさらに減らすために,カーソル固定ではなく非コミット読み取りを使用してください。

ロック・リストがいっぱいになると,ロック調整が行のロックよりも表のロックを多く行うので,パフォーマンスが低下する場合があり,これによって,データベースの共有オブジェクトでの並列性が低下します。さらに,アプリケーション間のデッドロックが増えるおそれがあり(すべてのアプリケーションが,限られた数の表ロックを待つため),これによってトランザクションがロールバックされることになります。データベースに対するロック要求の最大数に達すると,アプリケーションがSQLCODE-912を受け取ります。

詳細については,DB2のマニュアルを参照してください。

推奨:

ロック調整によってパフォーマンスの問題が生じている場合,このパラメーターかmaxlocksパラメーターの値を増やす必要があります。データベース・システム・モニターを使用すると,ロック調整が起きているかどうかを判別できます。

次のステップは,ロック・リストに必要なページ数を決定するのに役立ちます。

ロック・リストのサイズの下限を計算します。ユーザー環境によって,次の計算式の中から1つを使用して計算します。

(512*x*maxappls)/4,096
  • 集線装置が使用できる状態になっている場合

(512*x*max_coordagents)/4,096
  • 集線装置が使用できる状態になっているパーティション・データベースの場合

(512*x*max_coordagents*データベース・パーティションの数)/4,096

ただし,512はアプリケーション当たりの平均ロック数の見積もりであり,xは,既存のロックがあるオブジェクトに対するそれぞれのロックに必要なバイト数(32ビット・プラットフォームでは36バイト,64ビット・プラットフォームでは56バイト)です。

ロック・リスト・サイズの上限を計算します。

(512*y*maxappls)/4,096

yはオブジェクトに対する最初のロックに必要なバイト数です(32ビットのプラットフォームの場合は72バイトで,64ビットのプラットフォームの場合は112バイトです)。

データに対する並列量を見積もり,また計算した上限と下限の間になるように,予測に基づいてlocklistの初期値を選択します。

次に記述されているように,データベース・システム・モニターを使用してこのパラメーターの値を調整します。

データベース・システム・モニターを使用すると,指定したトランザクションによって保持される最大ロック数を判別できます。

この情報は,アプリケーション当たりのロックでの見積もり数の検査または調整に役立ちます。この妥当性検査を実行するには,モニター情報がアプリケーション・レベルではなく,トランザクション・レベルで提供されていることに注意して,複数のアプリケーションをサンプルとする必要があります。

また,maxapplsを増やしたか,または実行中のアプリケーションが頻繁にコミットを実行していない場合は,locklistの増加が必要になる場合もあります。

このパラメーターを変更した場合は,アプリケーションの再バインド(REBINDコマンドを使用)を考慮してください。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

LogbufSZ

(LOGBUFSZ)

ログ・バッファー・サイズ。ページ(4キロバイト)単位。

word

No

すべて

SQLF_DBTN_LOGBUFSZ

詳細説明:

このパラメーターを使用すると,データベース・ヒープの量(dbheapパラメーターで定義)を指定して,ログ・レコードをディスクに書き込む前に,ログ・レコードのバッファーとして使用できます。次のどれかのときに,ログ・レコードがディスクに書き込まれます。

  • mincommit構成パラメーターによって定義されたように,トランザクションのコミット,またはトランザクションのグループのコミットが行なわれたとき。

  • ログ・バッファーがいっぱいになったとき。

  • その他の幾つかの内部データベース・マネージャー・イベントの結果として。

また,このパラメーターはdbheapパラメーター以下でなければなりません。ログ・レコードのバッファリングは,ログ・レコードのディスクへの書き込み頻度が小さくなり,一度により多くのログ・レコードが書き込まれるため,より効率的なロギング・ファイル入出力になります。

詳細については,DB2のマニュアルを参照してください。

推奨:

専用ログ・ディスクに相当数の読み取り活動がある場合,またはディスクの使用率が高い場合,バッファー域のサイズを大きくしてください。このパラメーターの値を増やす場合は,ログ・バッファー域が,dbheapパラメーターでコントロールされるスペースを使用するので,dbheapパラメーターも考慮してください。

データベース・システム・モニターを使用すると,特定トランザクション(または作業単位)で使用されたログ・バッファー・スペースの量を判別できます。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Max Connections

(MAX_CONNECTIONS)

クライアント接続の最大数。

long

No

すべて

SQLF_KTN_MAX_CONNECTIONS

詳細説明:

このパラメーターは,インスタンスに接続できるアプリケーションの最大数をコントロールします。通常,各アプリケーションにはコーディネーター・プログラム・エージェントが割り当てられます。エージェントは,アプリケーションとデータベースの間の操作を容易にします。このパラメーターにデフォルト値が使用される場合,集線装置機能は活動化されません。結果として,各エージェントは専用メモリーを使用して機能し,データベース・マネージャーと,バッファー・プールなどのデータベース・グローバル・リソースをほかのエージェントと共有します。パラメーターがデフォルトよりも大きな値に設定されると,集線装置機能が活動化されます。集線装置の意図は,1つのクライアント・アプリケーションに対するサーバ・リソースを,DB2Connectゲートウェイによって10,000よりも多いクライアント接続を扱うことができるまで削減することです。

値が-1では,限度がmax_coordagentsであることを示します。

以前のバージョンのDB2では,このプログラムはmax_logicagentsという名前で呼ばれていました。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Max Coordagents

(MAX_COORDAGENTS)

コーディネーター・エージェントの最大数。

long

No

すべて

SQLF_KTN_MAX_COORDAGENTS

詳細説明:

集線装置がオフのとき,つまり,max_connectionsがmax_coordagentsに等しい場合,このパラメーターは,パーティションまたは非パーティション・データベース環境でサーバ上に同時にあるコーディネーター・エージェントの最大数を決定します。

データベースに接続する,またはインスタンスにアタッチするローカルまたはリモートのアプリケーションごとに1つのコーディネーター・エージェントが獲得されます。インスタンスへのアタッチを必要とする要求には,CREATEDATABASE,DROPDATABASE,およびデータベース・システム・モニター・コマンドがあります。

集線装置がオンの場合,つまり,max_connectionsがmax_coordagentsより大きいときは,接続の数がそれにサービスするためのコーディネーター・エージェントの数よりも多くなります。アプリケーションがアクティブ状態であるのは,アプリケーションにサービスするコーディネーター・エージェントがある場合だけです。コーディネーター・エージェントがない場合,アプリケーションは非アクティブ状態です。アクティブ・アプリケーションからの要求には,データベース・コーディネーター・エージェント(およびSMPまたはMPP構成内のサブエージェント)がサービスします。非アクティブ・アプリケーションからの要求はキューに入れられ,そのアプリケーションにサービスするデータベース・コーディネーター・エージェントが割り当てられると,アプリケーションがアクティブになります。したがって,このパラメーターを使用すると,システムに対するロードをコントロールできます。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Maxappls

(MAXAPPLS)

アクティブ・アプリケーションの最大数。

word

No

すべて

SQLF_DBTN_MAXAPPLS

詳細説明:

このパラメーターは,データベースに(ローカルとリモートの両方で)接続できる並列アプリケーションの最大数を指定します。データベースにアタッチしている各アプリケーションが,幾つかの専用メモリーを割り振るので,同時アプリケーションの数を多くすると,多くのメモリーが使用されるおそれがあります。

maxapplsをAutomaticに設定すると,接続されたアプリケーションを幾つでも任意の数だけ使用できるという効果が生じます。DB2では,新しいアプリケーションをサポートするために必要なリソースを動的に割り振ります。

このパラメーターをAutomaticに設定したくない場合は,このパラメーターの値は,接続されたアプリケーションの数に,これらと同じアプリケーションで2フェーズ・コミットおよびロールバックを完了する処理で同時に実行される数を加えた合計に等しいか,それよりも大でなければなりません。次に,どのようなときでも発生するおそれがある未確定トランザクション数をこの合計に追加します。

アプリケーションがデータベースへの接続を試みたときに,maxapplsの値にすでに達していた場合は,すでに最大数のアプリケーションがデータベースに接続されていることを示すエラーが,アプリケーションに返されます。

より多くのアプリケーションがData Links Managerを使用するときは,maxapplsの値を増やさなければなりません。次の公式を使用して,必要な値を計算します。

<maxappls>=5*(ノードの数)+(Data Links Managerを使用するアクティブ・アプリケーションのピーク数)

Data Links Managerの最大サポート値は2,000です。

パーティション・データベース環境下では,これはデータベース・パーティションに対して並行して活動状態であるアプリケーションの最大数です。このパラメーターは,サーバがアプリケーションのコーディネーター・プログラム・ノードであるかどうかにかかわらず,データベース・パーティション・サーバ上のデータベース・パーティションに対する活動アプリケーションの数を制限します。パーティション・データベース環境下のカタログ・ノードでは,この環境下のすべてのアプリケーションがカタログ・ノードへの接続を要求するため,ほかのタイプの環境での場合よりも高いmaxapplsの値が必要です。

推奨:

maxlocksパラメーターを低くしないでこのパラメーターの値を増やしたり,locklistパラメーターを増やしたりすると,アプリケーション限界ではなくロック(locklist)のデータベース限界に達し,その結果ロック・エスカレーションの問題が広がることになります。

ある程度については,アプリケーションの最大数もmaxagentsによって決まります。使用できるエージェント(maxagents)だけでなく,使用できる接続(maxappls)がある場合,アプリケーションはデータベースにしか接続できません。さらに,アプリケーションの最大数は,max_coordagents構成パラメーターによってもコントロールされます。max_coordagentsに達している場合,新しいアプリケーション(すなわち,コーディネーター・エージェント)を始動できません。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Maxcagents

(MAXCAGENTS)

同時エージェントの最大数。

long

No

すべて

SQLF_KTN_MAXCAGENTS

詳細説明:

データベース・マネージャー・トランザクションを同時に実行中であることが可能なデータベース・マネージャー・エージェントの最大数。このパラメーターは,多くのアプリケーション活動が同時に実行される期間中に,システムの負荷をコントロールするために使用されます。例えば,多数の接続が必要なシステムがあるのに,その接続用の記憶容量に制限がある場合などです。このパラメーターの調整は,多くの活動が同時に実行される期間が,極端なオペレーティング・システム・ページングの原因となるような環境で有効です。

このパラメーターは,データベースに接続できるアプリケーションの数を制限しません。これは,データベース・マネージャーが一度に並行して処理できるデータベース・マネージャー・エージェント数だけを制限しますが,これによって,処理のピーク時にシステム資源の使用率を制限できます。

値が-1の場合は,限度がmax_coordagentsであることを示します。

推奨:

ほとんどの場合に,このパラメーターのデフォルト値を使用できます。多くのアプリケーションを同時に実行することによって問題が生じている場合は,ベンチマーク・テストを使用してこのパラメーターを調整し,データベースのパフォーマンスを最適化できます。

監視対象のDB2がV9.5以降の場合,非推奨項目となり正しい値を収集できません。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Maxfilop

(MAXFILOP)

アプリケーション単位の最大データベース・ファイル・オープン数。

word

No

すべて

SQLF_DBTN_MAXFILOP

詳細説明:

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

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

また,このパラメーターを使用すると,エージェント単位のファイル・ハンドル数を制限すれば,データベース・マネージャーで使用されるファイル・ハンドルの総計がオペレーティング・システム限度を超えることのないようにすることもできます。なお,実際の数は,同時に稼働するエージェントの数に応じて異なります。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Maxlocks

(MAXLOCKS)

エスカレーション前のロック・リストの最大パーセント。

word

No

すべて

SQLF_DBTN_MAXLOCKS

詳細説明:

ロック・エスカレーションとは,行ロックを表ロックで置き換えて,リスト内のロック数を減らす処理のことです。このパラメーターでは,アプリケーションによって保持されるロック・リストのパーセントを定義します。このパーセントに達するまでデータベース・マネージャーはエスカレーションを実行しません。ある1つのアプリケーションによって保持されているロックの数が,合計ロック・リスト・サイズに対してこのパーセントに達すると,そのアプリケーションによって保持されているロックに関してロック・エスカレーションが行われます。ロック・リストがスペースを使い尽くした場合も,ロック・エスカレーションが発生します。

データベース・マネージャーは,アプリケーションのロック・リストを調べ,行ロック数が最も多い表を検索して,ロック・エスカレーションの対象となるロックを判別します。行ロックを単一の表ロックで置き換えたあと,maxlocks値を超えることがなくなっていれば,ロック・エスカレーションは停止します。そうならない場合は,保持されているロック・リストのパーセンテージがmaxlocksの値より低くなるまで,ロック・エスカレーションは続きます。maxlocksパラメーターにmaxapplsパラメーターを掛けた値が100より小であってはなりません。

推奨:

次の公式を使用すると,アプリケーションが平均ロック数の2倍のロックを保留できるように,maxlocksを設定できます。

maxlocks=2*100/maxappls

ただし,平均の2倍を達成するために2が使用され,100は許容最大パーセント値を表します。同時に実行するアプリケーションの数が少ない場合は,上記の公式に代えて次の公式を使用できます。

maxlocks=2*100/(同時に実行するアプリケーションの平均数)

maxlocksの設定時に考慮する必要のある事項の1つに,ロック・リスト(locklist)のサイズとの併用があります。ロック・エスカレーションが行われる前にアプリケーションが保持するロックの数での実際の限度は,次のとおりです。

  • 32ビットシステムの場合

maxlocks*locklist*4,096/(100*36)
  • 64ビットシステムの場合

maxlocks*locklist*4,096/(100*56)

ただし,4,096は1ページのバイト数,100はmaxlocksに許容される最大のパーセント値,36は32ビット・システムの場合での,1つのロック当たりのバイト数,56は64ビット・システムの場合での,1つのロック当たりのバイト数です。アプリケーションの1つで1,000ロックが必要であることがわかっていて,しかもロック・エスカレーションが行われないようにしたい場合は,この公式のmaxlocksおよびlocklistの値を選択すれば,結果は1,000より大になります(maxlocksに10を,locklistに100を使用すると,この公式によって,必要な1,000ロックより大という結果が得られます)。

maxlocksの設定が低過ぎると,ほかの同時アプリケーションにまだ十分のロック・スペースがあるときに,ロック・エスカレーションが行われます。maxlocksの設定が高過ぎると,一部のわずかなアプリケーションだけでロック・スペースのほとんどを使用してしまうおそれがあり,それ以外のアプリケーションではロック・エスカレーションを実行する必要が生じます。この場合にロック・エスカレーションが必要になるということは,並行性が低下する結果になります。

データベース・システム・モニターを使用すると,この構成パラメーターの追跡および調整に役立ちます。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Maxtotfilop

(MAXTOTFILOP)

最大合計オープン・ファイル数。

word

No

すべて

SQLF_KTN_MAXTOTFILOP

詳細説明:

このパラメーターは,単一のデータベース・マネージャー・インスタンスで実行中の,すべてのエージェントとほかのスレッドがオープンできる,ファイルの最大数を定義します。ファイルをオープンすればこの値を超えた場合,エラーがアプリケーションに返されます。

注:

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

値は常にゼロを表示します。

推奨:

このパラメーターを設定する場合,データベース・マネージャー・インスタンス内の各データベースで使用できるファイル・ハンドルの数を考慮してください。このパラメーターの上限の見積もりは,次のようにして行います。

インスタンス内のそれぞれのデータベースごとにオープンできるファイル・ハンドルの最大数を,次の公式を使用して計算します。

maxappls*maxfilop

上の結果を合計し,その値がパラメーターを超えていないかを調べます。

新しいデータベースを作成する場合は,このパラメーターの値をもう一度見積もり直してください。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Min Priv Mem

(MIN_PRIV_MEM)

最小コミット済み専用メモリー。ページ(4キロバイト)単位。監視対象がDB2のV9.1以降の場合は,非推奨となるため正しい値を収集できません。

ulong

No

すべて

SQLF_KTN_MIN_PRIV_MEM

詳細説明:

このパラメーターは,データベース・マネージャー・インスタンスが始動(db2start)したときに,データベース・サーバ処理が専用仮想メモリーとして予約されるページ数を指定します。サーバがより大きな専用メモリーを必要とする場合は,必要時に,サーバがオペレーティング・システムからメモリーを取得しようとします。

注:

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

値は常にゼロを表示します。

推奨:

デフォルト値を使用してください。

データベース・サーバにより多くのメモリーをコミットしたい場合,このパラメーターの値を変更すればよいだけです。このアクションによって,割り振り時間が節約されます。しかし,非DB2アプリケーションのパフォーマンスに影響を与えるおそれがあるため,その値を高く設定し過ぎないように注意してください。

監視対象のDB2がV9.1以降の場合,非推奨項目となり正しい値を収集できません。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Mon Heap SZ

(MON_HEAP_SZ)

データベース・システム・モニター・ヒープ・サイズ。ページ(4キロバイト)単位。

word

No

すべて

SQLF_KTN_MON_HEAP_SZ

詳細説明:

このパラメーターは,データベース・システム・モニター・データに割り振られるメモリーの大きさ(ページ数)を決定します。メモリーは,スナップショットの取得,モニター・スイッチのオン,モニターのリセット,またはイベント・モニターの活動化といった,データベースのモニター活動を実行するときにモニター・ヒープから割り振られます。

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

推奨:

活動のモニターに必要なメモリーの量は,スイッチが設定されるモニター・アプリケーション(スナップショットまたはイベント・モニターを取るアプリケーション)の数と,データベース活動のレベルに依存します。

次の計算式では,モニター・ヒープに必要なおおよそのページ数が算出されます。

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

このヒープ内の使用できるメモリーが使い尽くされた場合,次のどれかが行われます。

  • 最初のアプリケーションが,このイベント・モニターが定義されているデータベースに接続すると,エラー・メッセージが管理通知ログに書き込まれます。

  • SETEVENTMONITORステートメントを使用して動的に開始されているイベント・モニターが失敗した場合は,エラー・コードがアプリケーションに戻されます。

  • モニター・コマンドまたはAPIサブルーチンが失敗した場合は,エラー・コードがアプリケーションに戻されます。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Num Iocleaners

(NUM_IOCLEANERS)

非同期ページ・クリーナーの数。

word

No

すべて

SQLF_DBTN_NUM_IOCLEANERS

詳細説明:

このパラメーターを使用すると,データベースの非同期ページ・クリーナーの数を指定できます。これらのページ・クリーナーは,バッファー・プール内のスペースがデータベース・エージェントによって必要とされる前に,変更済みページをバッファー・プールからディスクに書き込みます。その結果,データベース・エージェントは,変更済みページが書き出されて,バッファー・プール内のスペースを使用できるようになるのを待機する必要がなくなります。こうして,データベース・アプリケーションの総体的なパフォーマンスが向上します。

このパラメーターをゼロに設定した場合は,開始されるページ・クリーナーがないので,その結果,バッファー・プールからディスクへのページ書き込みのすべてを,データベース・エージェントが実行することになります。データベースが多くの物理ストレージ・デバイスにわたって保管されている場合は,物理ストレージ・デバイスの1つがアイドル状態になる可能性が高いので,このパラメーターがデータベースに重大なパフォーマンス上の影響を及ぼすおそれがあります。ページ・クリーナーが構成されていない場合は,周期的にログがいっぱいになる状態がアプリケーションで検出されるおそれがあります。

データベースを使用するアプリケーションが,主として,データを更新するトランザクションで構成されている場合は,クリーナーの数を増やすと,パフォーマンスが向上します。ページ・クリーナーの数を増やすと,どの時点でも,ディスク上での,データベースの内容の最新性が増すため,停電などのソフト障害からのリカバリー時間も短縮されます。

推奨:

このパラメーターの値を設定する際は,次の要因を考慮してください。

  • アプリケーション・タイプ

    更新が行われない照会専用データベースの場合は,このパラメーターはゼロになるように設定します。例外は,照会ワークロードによってTEMP表が多数作成される結果になる(これについては,EXPLAINユーティリティーを使用して判別できます)場合です。

    データベースに対してトランザクションが実行される場合は,このパラメーターは,1とデータベース用として使用されている物理ストレージ・デバイスの台数の間になるように設定します。

  • ワークロード

    更新トランザクションの率が高い環境では,ページ・クリーナーの数を増やして構成する必要があります。

  • バッファー・プール・サイズ

    バッファー・プールの容量が大きい環境でも,ページ・クリーナーの数を増やして構成する必要があります。

データベース・システム・モニターを使用すると,バッファー・プールからの書き込みアクティビティーについてのイベント・モニターから得られる情報を使用して,この構成パラメーターを調整する場合に役立ちます。

次の2つの条件が真の場合は,パラメーターの値を小さくできます。

  • pool_data_writesがおよそpool_async_data_writesに等しい。

  • pool_index_writesがおよそpool_async_index_writesに等しい。

次の2つの条件でどちらかが真の場合は,パラメーターの値を大きくする必要があります。

  • pool_data_writesがpool_async_data_writesよりもはるかに大きい。

  • pool_index_writesがpool_async_index_writesよりもはるかに大きい。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Num Ioservers

(NUM_IOSERVERS)

入出力サーバの数。

word

No

すべて

SQLF_DBTN_NUM_IOSERVERS

詳細説明:

入出力サーバは,データベース・エージェントの代わりに,バックアップおよびリストアなどのユーティリティーによるプリフェッチ入出力および非同期入出力を実行するために使用されます。このパラメーターは,データベースのための入出力サーバ数を指定します。あるデータベースに対して,この入出力数を超えるプリフェッチおよびユーティリティーを行うことはできません。入出力サーバは,出された入出力が進行中の間,待ち状態になります。非プリフェッチ入出力は,データベース・エージェントから直接スケジュールされ,その結果num_ioserversによって制限されます。

推奨:

システム内のすべての入出力装置を完全に利用するために適正な値は,一般にデータベースが置かれている物理装置数に1または2を加えたものです。各入出力サーバにはそれぞれ最小限のオーバーヘッドが発生し,未使用の入出力サーバはアイドル状態のままになるため,追加の入出力サーバを構成することを推奨します。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Num Poolagents

(NUM_POOLAGENTS)

エージェント・プール・サイズ。

long

No

すべて

SQLF_KTN_NUM_POOLAGENTS

詳細説明:

このパラメーターの値がゼロの場合,必要に応じてエージェントが作成されるので,現行の要求の完了時にそれらのエージェントが終了するおそれがあります。値がmaxagentsで,プールが関連サブエージェントでいっぱいの場合は,新しいコーディネーター・ノードは作成できないため,サーバはコーディネーター・ノードとして使用できません。

推奨:

同時に接続しているアプリケーションの数が少ない意思決定支援環境を実行している場合,num_poolagentsを小さい値に設定して,エージェント・プールがアイドル・エージェントでいっぱいにならないようにしてください。

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

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

PckcacheSZ

(PCKCACHESZ)

パッケージ・キャッシュ・サイズ。ページ(4キロバイト)単位。

ulong

No

すべて

SQLF_DBTN_PCKCACHESZ

詳細説明:

このパラメーターは,データベース共有メモリーから割り振られ,データベース上の静的および動的SQLステートメントのセクションをキャッシュするために使用されます。パーティション・データベース・システムでは,データベース・パーティションごとに1つのパッケージがあります。

パッケージをキャッシュすると,データベース・マネージャーの場合はパッケージを再ロードするときにシステム・カタログにアクセスする必要がなくなるために内部オーバーヘッドが減少し,また動的SQLの場合はコンパイルする必要がなくなることによって,内部オーバーヘッドが減少します。セクションは,次のどれかの状況になるまで,パッケージ・キャッシュ内に保持されます。

  • データベースがシャットダウンされるとき

  • パッケージまたは動的SQLステートメントが無効にされるとき

  • キャッシュがスペースを使い果たしたとき

静的または動的SQLステートメントのセクションのこのキャッシュは,データベースに接続されたアプリケーションによって同じステートメントが複数回使用される場合に,特にパフォーマンスを改善できます。これは,トランザクション処理アプリケーションでは特に重要です。

デフォルト(-1)を使うことによって,ページ割り振りの計算に使用される値は,maxappls構成パラメーターに指定された値の8倍になります。maxapplsの8倍が32よりも小さい場合は,例外となります。この場合,デフォルト値-1を指定するとpckcacheszが32に設定されます。

推奨:

このパラメーターを調整するときは,パッケージ・キャッシュ用に予約されている余分なメモリーが,バッファー・プールまたはカタログ・キャッシュなど別の目的のために割り振られた場合にさらに有効に使用できるかどうかを考慮する必要があります。上記の理由によって,このパラメーターの調整時には,ベンチマーク技法を使用してください。

このパラメーターの調整は,幾つかのセクションが最初に使用され,その後は2,3のセクションだけが繰り返し実行される場合に特に重要です。キャッシュが大き過ぎると,最初のセクションのコピーを保留している分だけメモリーがむだになっています。

これらのモニター・エレメントは,この構成パラメーターを調整する必要があるかどうかの判別に役立ちます。

  • パッケージ・キャッシュ参照数

    pkg_cache_lookups

  • パッケージ・キャッシュ挿入

    pkg_cache_inserts

  • パッケージ・キャッシュ最高水準点

    pkg_cache_size_top

  • パッケージ・キャッシュ・オーバーフロー

    pkg_cache_num_overflows

注:

パッケージ・キャッシュは作業キャッシュであるため,このパラメーターをゼロに設定することはできません。現在実行されているSQLステートメントのすべてのセクションを保留するには,このキャッシュに十分なメモリーが割り振られていなければなりません。現行の必要スペース以上のスペースが割り振られている場合,セクションがキャッシュされます。これらのセクションは,次に必要とされるときにはロードやコンパイルをしないで実行できます。

pckcacheszパラメーターによって指定された制限は柔軟性のある制限です。メモリーがデータベース共有セットでまだ使用できる場合,必要であればこの制限を超えることができます。パッケージ・キャッシュがいちばん大きくなったサイズを判別するには,pkg_cache_size_topモニター・エレメントを使用し,pckcacheszパラメーターによって指定された制限を超えた回数を判別するには,pkg_cache_num_overflowsモニター・エレメントを使用できます。

注意事項

このフィールドの値はulong形式で格納するため,(-1)を(4294967295)と表示します。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Query Heap SZ

(QUERY_HEAP_SZ)

照会ヒープ・サイズ。ページ(4キロバイト)単位。

long

No

すべて

SQLF_KTN_QUERY_HEAP_SZ

詳細説明:

このパラメーターは,照会ヒープに割り振ることができるメモリーの最大数を指定します。照会ヒープは,各照会をエージェントの専用メモリーに格納するために使用されます。各照会の情報は,入力と出力SQLDA,ステートメント・テキスト,SQLCA,パッケージ名,作成者,セクション番号,および整合性トークンで構成されます。このパラメーターは,アプリケーションに,エージェント内で不要に大きな仮想メモリーを消費させないために提供されています。

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

割り振られる初期照会ヒープは,aslheapszパラメーターによって指定されたアプリケーション・サポート層ヒープと同じサイズです。照会ヒープのサイズは2以上でなければならず,aslheapszパラメーター以上でなければなりません。この照会ヒープの大きさが不十分なために指定された要求を処理できない場合は,query_heap_szを超えない範囲で,要求に必要なサイズまで再割り振りが行われます。この新しい照会ヒープがaslheapszの1.5倍を超える大きさの場合,照会が終了したときに照会ヒープはaslheapszのサイズまで再度割り振られます。

推奨:

ほとんどの場合,デフォルト値が効率的です。最小値として,query_heap_szを少なくともaslheapszの5倍より大きい値に設定してください。これによって,aslheapszより大きな照会が使用でき,指定時にオープンされる3つまたは四つのブロック・カーソルに追加メモリーが提供されます。

とても大きなLOBを持っている場合,このパラメーターの値を増やして,照会ヒープをそれらのLOBを収容する大きさにできます。

監視対象のDB2がV9.5以降の場合,非推奨項目となり正しい値を収集できません。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Record Time

(RECORD_TIME)

レコードに格納されたパフォーマンスデータの収集終了時刻。

time_t

No

すべて

Agent Collector

詳細説明:

特になし。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Record Type

(INPUT_RECORD_TYPE)

レコード名。常に「DCFE」。

char(8)

No

すべて

Agent Collector

詳細説明:

特になし。

PFM - View名

(PFM - Manager名)

説明

要約

形式

デルタ

サポートVR

制約

データソース

Sortheap

(SORTHEAP)

ソート・ヒープ・サイズ。ページ(4キロバイト)単位。

ulong

No

すべて

SQLF_DBTN_SORTHEAP

詳細説明:

このパラメーターでは,専用ソートで使用される専用メモリー・ページの最大数,または共有ソートで使用される共有メモリー・ページの最大数を定義します。ソートが専用ソートの場合は,このパラメーターによってエージェント専用メモリーに影響が生じます。ソートが共有ソートの場合は,このパラメーターによってデータベース共有メモリーに影響が生じます。それぞれのソートには,必要に応じてデータベース・マネージャーによって割り振られる別々のソート・ヒープがあります。このソート・ヒープは,データがソートされる領域です。オプティマイザーによる指示があった場合は,オプティマイザーが提供する情報を使用して,このパラメーターによって指定されたソート・ヒープよりも小さいソート・ヒープが割り振られます。

推奨:

ソート・ヒープを使用して作業する場合は,次の事項を考慮する必要があります。

  • 適切な索引によってソート・ヒープの使用を最小化できる。

    ハッシュ結合バッファーおよび動的ビットマップ(索引ANDおよびStarJoinで使用される)では,ソート・ヒープ・メモリーを使用する。したがって,これらの技法が使用されるときは,このパラメーターのサイズを大きくします。

  • ラージ・ソートが頻繁に必要なときは,このパラメーターのサイズを大きくする。

    このパラメーターの値を大きくするときは,データベース・マネージャー構成ファイルにあるsheapthresパラメーターも調整する必要があるかどうか調べる必要がある。

  • ソート・ヒープ・サイズは,オプティマイザーがアクセス・パスを決定する際に使用する。

    このパラメーターを変更した場合は,アプリケーションの再バインド(REBINDコマンドを使用)を考慮してください。