9.2.19 バッファに関するオペランド
- ◆ pd_sql_object_cache_size = SQLオブジェクト用バッファ長
-
〜＜符号なし整数＞（単位：キロバイト）
-
32ビットモードの場合：((22〜256000))《（pd_max_usersの値＋n）×22》
-
64ビットモードかつ推奨モードの場合：((22〜2000000))《（pd_max_usersの値＋n）×40》
-
64ビットモードかつ0904互換モードの場合：((22〜2000000))《（pd_max_usersの値＋n）×22》
n：HiRDB/パラレルサーバでマルチフロントエンドサーバ構成を適用する場合は4，それ以外は3
SQLオブジェクトを格納するバッファ（共用メモリ）の大きさをキロバイト単位で指定します。
- 《指定値の目安》
-
-
SQLオブジェクトは，ユーザごとにトランザクションが終了するまでバッファに保存されます。したがって，同時に実行するトランザクションのSQLオブジェクトがバッファに格納できる大きさが必要です。
-
SQLオブジェクト用バッファのヒット率が低い場合，SQL文解析処理のオーバヘッドによって性能が低下することがあります。
-
静的SQLのSQLオブジェクトはトランザクション終了後もバッファに空きがなくなるまで保存して，同一UAPを実行する複数のユーザで共用することで，SQL解析処理の削減を図ります。バッファを有効に利用するためには，使用頻度の高いUAPのSQLオブジェクトがバッファに常駐するようにバッファを確保してください。
-
バッファ長の見積もり時は，まずUAPで発行するSQL文のSQLオブジェクト長からUAP実行に必要なバッファ長を見積もります。次に，同時に実行されるUAPと同時実行ユーザ数を考慮して必要なバッファ長を算出してください。
-
1SQL文のSQLオブジェクト長の見積もり方法については，「SQLオブジェクト用バッファ長（pd_sql_object_cache_size）の見積もり式」を参照してください。
-
- 《指定値のチューニング方法》
-
SQLオブジェクト用バッファ長のチューニングについては，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_sql_object_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「ディクショナリサーバが使用する共用メモリの計算式」の「計算式1」
-
「バックエンドサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
-
- ◆ pd_def_buf_control_area_assign = INITIAL｜TRAN
-
表定義情報用バッファ，ビュー解析情報用バッファ，ユーザ定義型情報用バッファ，及びルーチン定義情報用バッファの管理領域をHiRDB開始時に一括して確保するか，又はトランザクション開始時に確保するかを指定します。
- INITIAL：
-
各種バッファの管理領域をHiRDB開始時に一括して確保します。この管理領域はHiRDBを終了するまで解放されません。
- TRAN：
-
各種バッファの管理領域をトランザクション開始時に確保します。この管理領域はトランザクション終了時に解放されます。
- 《指定値の目安》
-
性能を重視する場合はINITIALを指定してください。トランザクション性能が向上します。ただし，TRAN指定時よりも共用メモリを多く必要とするため，メモリ所要量を見直してください。共用メモリの見積もりについては，マニュアル「HiRDB Version 9 システム導入・設計ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_def_buf_control_area_assignオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
- ◆ pd_thread_max_stack_size = 1スレッドが使用する最大スタックサイズ
-
〜＜符号なし整数＞((0〜OSが許容する最大スタックサイズ（最大2047）))《0》（単位：メガバイト）
このオペランドはHiRDB/パラレルサーバ限定のオペランドです。
1スレッドが使用するスタックサイズの最大値を指定します。0を指定するか，又はこのオペランドを省略した場合，1スレッドが使用するスタックサイズを制限しません。HiRDBは擬似スレッド制御をしているため，独自に確保したメモリをスタックとして割り当てています。
- 《利点》
-
UAPの不良，又はUAPからの複雑なSQLの要求などによって，1スレッドが多量のシステムリソースを使用することがあります。これが原因でOSがハングアップすることがあります。このオペランドを指定すると，1スレッドが使用するスタックサイズを制限できるため，OSのハングアップが防止できます。
- 《注意事項》
-
このオペランドの指定値が，OSが許容する最大スタックサイズ以下であることを確認してください。
- ◆ pd_thread_stack_expand_size = 1スレッド当たりのスタック拡張サイズ
-
〜＜符号なし整数＞((0〜2146435072))《0》（単位：バイト）
HiRDBが制御するスレッドの，1スレッド当たりのスタックサイズを拡張するオペランドです。
通常，このオペランドは省略します。保守員から依頼があった場合に変更してください。
- ◆ pd_table_def_cache_size = 表定義情報用バッファ長
-
〜＜符号なし整数＞（単位：キロバイト）
-
32ビットモードの場合：((100〜65535))
![[図データ]](GRAPHICS/ZU040010.GIF)
-
64ビットモードかつ推奨モードの場合：((100〜2000000))《16000》
-
64ビットモードかつ0904互換モードの場合：((100〜2000000))
n：HiRDB/パラレルサーバでマルチフロントエンドサーバ構成を適用する場合は4。それ以外は3。
一度使用した表と順序数生成子の定義情報を格納するバッファ（共用メモリ）の大きさをキロバイト単位で指定します。表と順序数生成子の定義情報は，SQL文の前処理時に使用します。また，このバッファ内の定義情報は，LRUで管理されます。
- 《利点》
-
-
一度使用した表と順序数生成子の定義情報を共用メモリ内に格納して，次回使用するときは入出力なしで使用できます。
-
動的SQLを多く使用する場合，性能が向上します。
-
ディクショナリサーバとの通信回数を削減できます（HiRDB/パラレルサーバの場合）。
-
- 《指定値の目安》
-
-
使用頻度が高い表と順序数生成子の定義情報長の合計値を指定してください。
-
1順序数生成子当たりの表定義情報バッファサイズは，8キロバイトです。
-
1表当たりの表定義情報用バッファ長の求め方については，「表定義情報用バッファ長（pd_table_def_cache_size）の見積もり式」を参照してください。なお，一時表の場合は，非分割表と同様として計算してください。
-
- 《指定値のチューニング方法》
-
表定義情報用バッファ長のチューニング方法については，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_table_def_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
-
- ◆ pd_auth_cache_size = ユーザ権限情報用バッファ長
-
〜＜符号なし整数＞((1〜100))《10》（単位：キロバイト）
-
0904互換モードの場合：《1》
ユーザ権限情報を格納するバッファ（共用メモリ）の大きさをキロバイト単位で指定します。
- 《指定値の目安》
-
-
ユーザ権限情報用バッファにはCONNECT権限，DBA権限，及び監査権限の情報を格納します。このバッファに情報がない場合はHiRDB接続時にディクショナリ表から情報を取得するため，応答時間が遅くなります。したがって，常時接続しているユーザ数分の情報を格納できるようにバッファ長を指定してください。
-
1ユーザ当たりのユーザ権限情報を格納するのに68バイト必要になります。それを基に計算してください。
-
- 《指定値のチューニング方法》
-
ユーザ権限情報用バッファ長のチューニング方法については，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_auth_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
-
- ◆ pd_view_def_cache_size = ビュー解析情報用バッファ長
-
〜＜符号なし整数＞（単位：キロバイト）
-
32ビットモードの場合：((0〜32000))
![[図データ]](GRAPHICS/ZU040020.GIF)
-
64ビットモードかつ推奨モードの場合：((0〜2000000))《30000》
-
64ビットモードかつ0904互換モードの場合：((0〜2000000))
n：HiRDB/パラレルサーバでマルチフロントエンドサーバ構成を適用する場合は4。それ以外は3。
ビュー解析情報を格納するバッファ（共用メモリ）の大きさをキロバイト単位で指定します。
- 《利点》
-
一度使用したビュー解析情報を共用メモリ内に格納して，次回使用するときは入出力なしで使用できます。
- 《指定値の目安》
-
使用頻度が高いビュー表のビュー解析情報用バッファ長の合計値を指定してください。ビュー解析情報用バッファ長の見積もりについては，「ビュー解析情報用バッファ長（pd_view_def_cache_size）の見積もり式」を参照してください。
- 《指定値のチューニング方法》
-
ビュー解析情報用バッファ長のチューニング方法については，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_view_def_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
-
- ◆ pd_type_def_cache_size = ユーザ定義型情報用バッファ長
-
〜＜符号なし整数＞《0》（単位：キロバイト）
-
32ビットモードの場合：((100〜65536))
-
64ビットモードの場合：((100〜2000000))
このオペランドは，ユーザ定義型に関するオペランドです。ユーザ定義型を使用する場合は，このオペランドを指定することをお勧めします。
ユーザ定義型の情報を格納するバッファ（共用メモリ）の大きさを，キロバイト単位で指定します。ユーザ定義型の情報を使用すると，その情報がこのバッファ内に格納されます。この情報はSQL文の前処理時に使用します。
- 《利点》
-
-
このバッファにユーザ定義型の情報を格納すると，このユーザ定義型の情報を次回使用するときに，ディクショナリ表をアクセスする必要がなくなります。そのため，入出力回数の削減や，CPU使用時間を短縮できます。
-
ディクショナリサーバとの通信回数が削減できます。
-
動的SQLを多く使用する場合，このオペランドを指定すると性能が向上します。
-
- 《指定値の目安》
-
使用頻度が高い表に定義してあるユーザ定義型の定義情報長を合計します。一つ当たりのユーザ定義型の定義情報長は，次に示す計算式から求めてください。
↑｛（（ 0.3＋0.2×ａ＋0.1×ｂ）＋３）÷４｝↑×４
（単位：キロバイト）
ａ：ユーザ定義型の属性数
ｂ：スーパタイプを継承したサブタイプ数
- 《指定値のチューニング方法》
-
ユーザ定義型情報用バッファ長のチューニング方法については，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_type_def_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
-
- ◆ pd_routine_def_cache_size = ルーチン定義情報用バッファ長
-
〜＜符号なし整数＞《300》（単位：キロバイト）
-
0904互換モードの場合：《100》
-
32ビットモードの場合：((0，20〜65536))
-
64ビットモードの場合：((0，20〜2000000))
次に示す定義情報を格納するバッファ（共用メモリ）の大きさをキロバイト単位で指定します。これらの定義情報はSQL文の前処理時に使用します。
-
プラグイン関数の定義情報
-
システム定義スカラ関数の定義情報
-
ルーチンの定義情報
- 《利点》
-
-
このバッファに前記の定義情報を格納すると，これらの情報を次回使用するときに，ディクショナリ表をアクセスする必要がなくなります。そのため，入出力回数の削減や，CPU使用時間を短縮できます。
-
ディクショナリサーバとの通信回数が削減できます。
-
- 《適用基準》
-
次に示すSQLを多く使用する場合に指定します。
-
プラグインを使用するSQL
-
システム定義スカラ関数を使用するSQL
-
ルーチンを使用するSQL
-
- 《指定値の目安》
-
このオペランドの指定値の求め方については，「ルーチン定義情報用バッファ長（pd_routine_def_cache_size）の見積もり式」を参照してください。
- 《指定値のチューニング方法》
-
ルーチン定義情報用バッファ長のチューニング方法については，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《注意事項》
-
このオペランドの指定値が全プラグイン提供関数の定義情報の合計値より小さい場合，プラグイン提供関数の定義情報はバッファ中に確保されません。
- 《各見積もり式への影響》
-
pd_routine_def_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-
-
- ◆ pd_registry_cache_size = レジストリ情報用バッファ長
-
〜＜符号なし整数＞((0〜65536))《10》（単位：キロバイト）
このオペランドは，プラグインに関するオペランドです。レジストリ情報を使用するプラグインを使用する場合は，このオペランドを指定することをお勧めします。HiRDB Text Search Plug-inを使用する場合は，指定することをお勧めします。
レジストリ情報を格納するバッファ（共用メモリ）の大きさを，キロバイト単位で指定します。レジストリ情報を使用すると，レジストリ情報がバッファ内に格納されます。レジストリ情報はSQL文の実行時に使用します。
- 《利点》
-
-
このバッファにレジストリ情報を格納すると，レジストリ情報を次回使用するときに，レジストリをアクセスする必要がなくなります。そのため，入出力回数の削減や，CPU使用時間を短縮できます。
-
ディクショナリサーバとの通信回数が削減できます。
-
レジストリ情報を多く使用するプラグインを使用する場合，このオペランドを指定すると性能が向上します。
-
- 《指定値の目安》
-
レジストリ情報用バッファ長は，次に示す計算式から求めてください。
↑（ 0.3＋ａ）↑×ｂ （単位：キロバイト）
ａ：レジストリキー長の平均長（単位：キロバイト）
レジストリキー値の平均長は次に示すSQLで求められます。
このSQLの結果の単位はバイトのため，キロバイトに変換してください。
SELECT AVG(KEY_LENGTH) FROM MASTER.SQL_REGISTRY
ｂ：レジストリキーの登録数
レジストリキーの登録数は次に示すSQLで求められます。
SELECT COUNT(*) FROM MASTER.SQL_REGISTRY
- 《指定値のチューニング方法》
-
レジストリ情報用バッファ長のチューニング方法については，マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。
- 《各見積もり式への影響》
-
pd_registry_cache_sizeオペランドの指定値を変更すると，次の見積もり式に影響があります。
マニュアル「HiRDB Version 9 システム導入・設計ガイド」：
-
「シングルサーバが使用する共用メモリの計算式」の「計算式1」
-
「フロントエンドサーバが使用する共用メモリの計算式」
-