このセクションでは、バッファプールとバッファプールキャッシュのパフォーマンス関連の問題についての一般的なアドバイスを提供します。
このセクションで説明する統計項目の詳細については、「バッファプールのロード／ロケート統計」を参照してください。
このセクションでは、次のトピックについて説明します。
Natural セッション内で Natural オブジェクトが初めて参照されると、バッファプールマネージャによってそのオブジェクトのディレクトリエントリが作成されます。 ディレクトリエントリは、オブジェクトを識別するために使用され、オブジェクトの名前、オブジェクトが存在するライブラリ（名前、データベース ID、ファイル番号）、バッファプール内のオブジェクトのアドレス（位置）などの情報が含まれています。
Natural ランタイムシステムでは、最近実行されたオブジェクト、それらのオブジェクトが存在するライブラリ（名前、データベース ID、ファイル番号）、および対応するバッファプールディレクトリエントリのアドレスが、Natural セッションの間、内部高速検索テーブルに記憶されます。
ユーザーが以前 Natural セッションで使用されたオブジェクトを呼び出すと、Natural ランタイムシステムによって、内部高速検索テーブルの情報がバッファプールマネージャに渡されます。これにより、バッファプールマネージャでは、通常検索手順ではなく、時間のかからない高速検索コールを実行できます（「高速検索コール」を参照）。 これは、オブジェクトを検索するための最も効果的な方法です。
バッファプール内のオブジェクトの位置が変更された場合、バッファプールマネージャでは、自動的に通常検索コールがスケジュールされます。 バッファプールから削除されたオブジェクトや別のオブジェクトによって上書きされたオブジェクトがバッファプールに再ロードされた場合、位置は通常変更されます。
内部高速検索テーブルには、最大 128 のエントリが含まれています。 高速検索テーブルは LOGON システムコマンドによってリセットし、通常検索コールを使用して再び埋める必要があります。 そのため、［LOGON］を実行するアプリケーションではパフォーマンスが失われます。
［Quick Locate Calls］に対する［Normal Locate Calls］の比率の高さは、各 LOGON での Natural アプリケーションの LOGON コマンドの使用によって内部高速検索テーブルがリセットされたことを示します。
steplib ライブラリの長いチェーンを介して Natural オブジェクトを検索すると、パフォーマンスに悪影響を与えます。
Natural ランタイムでは、要求されたオブジェクトが見つかるまで、各 steplib に対してバッファプールマネージャへのコールが発行されます。 ただし、通常、要求されたオブジェクトを含まない steplib ライブラリへの不要なコールは回避されます。 Natural ユーティリティ DBLOG を使用して、バッファプールでの検索順序をモニタリングできます。詳細については、「検索順序のモニタリング」を参照してください。
BPSFI プロファイルパラメータ（『パラメータリファレンス』ドキュメントを参照）の設定に応じて、追加のデータベースコールが必要となる場合があります。
steplib チェーンの長さは、［Normal Locate Calls］（steplib 検索を含まず）に対する［Normal Locate Calls］（steplib 検索を含む）の比率の高さによって示され、次のように計算されます。
Normal Locate Calls：（［Normal Locate Calls］ - ［STEPLIB Searches］)
デフォルトの steplib チェーン（FUSER のライブラリ SYSTEM、FNAT のライブラリ SYSTEM）を検索する場合、SYSTEM（FNAT）からオブジェクトをロードしようとするたびに、次のような結果になります。
3［Normal Locate Calls］と 2［STEPLIB Searches］
説明：
3 件の通常検索コールは、現在のライブラリ、ライブラリ SYSTEM（FUSER）、およびライブラリ SYSTEM（FNAT）の検索が原因で発生します。 オブジェクトは現在のライブラリにもライブラリ SYSTEM（FUSER）にも格納されないため、（少なくとも）2
件の通常検索コールは失敗します。 上記の式を使用すると、比率は 3 対 1 になります。
オブジェクトが現在のライブラリにある場合、結果は次のようになります。
1 通常検索コールと 0（ゼロ）［STEPLIB Searches］。 上記の式を使用すると、比率は 1 対 1 になります。
多くの Natural オブジェクトを含み、各オブジェクトがこれまでほとんど実行されていないアプリケーションは、バッファプールのパフォーマンスに大きな影響を与えます。 いずれのオブジェクトもバッファプールでの存続期間が短く、多くのオブジェクトをシステムファイルからロードする必要があります。 パフォーマンス上の理由から、アプリケーションでは、複数のオブジェクトに含まれている同一のソースコードを 1 つのオブジェクトに移動するなどして、できる限りオブジェクトを再利用する必要があります。
機能を使用して、オブジェクトの使用を確認することができます（「オブジェクトのリスト」セクションを参照）。 例えば、［Max］列には、オブジェクトを実行したアプリケーションの最大数に関する情報が表示され、［TotalUC］列には、バッファプールにロードされたオブジェクトの検索コールの合計数が表示されます。
オブジェクトは、機能を使用するか、プリロードリストで指定して、個別に常駐にすることができます（「プリロードリストの管理」を参照）。
アプリケーションごとに要件が異なるため、ローカルバッファプールとグローバルバッファプールの使い分けに関する一般的な推奨事項はありません。 ただし、経験則から、次のトピックについて一般的なアドバイスを提供することはできます。
このセクションでは、次のトピックについて説明します。
異なるアプリケーション環境にローカルバッファプールを割り当てることができる場合は、単一の大きいバッファプールではなく、複数の小さいローカルバッファプールを使用して、パフォーマンスを向上させることができます。
例えば、CICS 環境で各 AOR（Application Operating Region）にローカルバッファプールを使用すると、通常はパフォーマンスが向上します。
同じ Natural オブジェクトを参照する異なるバッチアプリケーションでは、個々のアプリケーションにローカルバッファプールを使用するのではなく、1 つの共通のグローバルバッファプールを使用すると、パフォーマンスが向上する場合があります。 その場合、各アプリケーションによって要求されるオブジェクトが、他のいずれかのアプリケーションによってグローバルバッファプールにすでにロードされている可能性が高くなります。
このセクションでは、Natural ユーティリティの DBLOG を使用してバッファプールでの検索順序をモニタリングする方法について説明します。
バッファプールでの検索順序をモニタリングするには
次のパラメータを設定して、Natural セッションを開始します。
LOG=ON DSIZE=(2 - 256) BPSFI=OFF
データベースロギングに十分なメモリを使用できる値に DSIZE を設定します。
次のシステムコマンドを入力します。
TEST DBLOG MENU
DBLOG メニューが表示されます。
［VB］の横にあるフィールドにマークを付けてバリューバッファオプションを選択し、ファンクションコード「B」を入力して DBLOG を有効にします。
プログラム例を実行します（次の例の PGM01）。
次のコマンドを再度入力します。
TEST DBLOG
次のような［DBLOG Trace］画面が表示されます。
16:00:30 ***** NATURAL TEST UTILITIES ***** 2005-05-17
User SAG - DBLOG Trace - Library TEST
M No Cmd DB FNR Rsp ISN ISQ CID CID(Hex) OP Pgm Line
_ 1 S1 10 1640 00000000 ATEST 5400
_ 2 RC 10 00000000 F ATEST 7110
_ 3 S1 10 32 00000000 0000
_ 4 S1 10 32 00000000 0000
_ 5 S1 10 32 00000000 0000
_ 6 S1 10 1640 232156 1 00000000 0000
_ 7 L3 10 1640 232157 NLBX D5D3C2E7 MA 0000
_ 8 RC 10 1640 NLBX D5D3C2E7 SF 0000
_ 9 S1 10 32 1002773 1 00000000 PGM01 0180
_ 10 S1 10 32 1002774 1 00000000 PGM01 0180
_ 11 RC 10 00000000 F PGM01 1530
_
_
_
_
_
_
Command ===>
Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
Help Print Exit Top Posi Bot - + Canc
|
［Cmd］（コマンド）列で、データベース ID（［DB］列）およびファイル番号（［FNR］列）によって示される FUSER システムファイルと FNAT システムファイルの S1 Adabas コマンドを探します。 オブジェクトが S1 コマンドでロードできない場合、最後の S1 コールの後に、［CID］列に NLBX コマンド ID が示された L3 コマンドが続きます。
［M］列の各 S1 エントリの横に「V」を入力してバリューバッファを選択します。 次のような［Value Buffer］ウィンドウが表示されます。
15:59:05 ***** NATURAL TEST UTILITIES ***** 2005-05-17
User SAG - DBLOG Trace - Library TEST
M No Cmd DB FNR Rsp ISN ISQ CID CID(Hex) OP Pgm Line
_ 1 S1 10 1640 00000000 ATEST 5400
_ 2 RC 10 00000000 F ATEST 7110
v +----------------------------------------------------------------------+ 0
_ ! _ Seq No .. 3 Value Buffer ! 0
_ ! 0000 * D4D4D640 40404040 D7C7D4F0 F1E74040 * TEST PGM01 * 0000 ! 0
_ ! 0010 * 00010000 00000000 00000000 00000000 * ? * 0010 ! 0
_ ! ! 0
_ ! 0020 * 00000000 00000000 00000000 00000000 * * 0020 ! 0
_ ! 0030 * 00000000 00000000 00000000 00000000 * * 0030 ! 0
_ ! 0040 * 00000000 00000000 00000000 00000000 * * 0040 ! 0
_ +----------------------------------------------------------------------+ 0
_
_
_
_
_
_
Command ===>
Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
Help Print Exit Top Posi Bot - + Canc
|
バリューバッファでは、オブジェクトが検索されたライブラリの名前（ここでは TEST）とオブジェクトの名前（ここでは PGM01）が表示されます。
バリューバッファは、選択した追加の各 S1 コマンドについて、同じオブジェクト名であるが異なるライブラリ名を表示します。 このことは、オブジェクトが現在のライブラリに見つからなかったこと、およびオブジェクトを見つけるために steplibs をスキャンする必要があったことを示します。
