スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド(UNIX(R)用)

[目次][索引][前へ][次へ]

22.5.4 SQLオブジェクト用バッファ長のチューニング

SQLオブジェクト用バッファ長pd_sql_object_cache_sizeオペランドの値)のチューニング方法を説明します。SQLオブジェクトで使用するバッファをチューニングするときには,次に示す内容を考慮してください。

●SQLオブジェクトとSQLオブジェクト用バッファの関係
HiRDBでは,UAP中のSQL文をSQL文ごとに解析して,UAPを実行するときに,実行形式のSQLオブジェクトを作成しています。このため,同じUAPを異なるユーザが後から実行する場合,発行したSQL文に対応するSQLオブジェクトが,既にSQLオブジェクト用バッファにあると,SQLオブジェクトを作成する時間を削減でき,発行したSQL文の処理時間を短縮できます。
したがって,SQLオブジェクト用バッファのヒット率が低い場合,バッファから出力されたSQL文のSQLオブジェクトは,再度同じSQL文を実行するときにSQL文を解析して,SQLオブジェクトを作成します。このため,データベースに対するアクセス件数が少ないSQL文の実行時には,長い処理時間が必要となります。
また,SQLオブジェクト作成に関しては,SQL文の解析時にアクセスする表の定義情報が表定義情報バッファにない場合,ディクショナリ表に対するアクセスを必要とするため,アクセスする表の数や列数,アクセス件数が多いときは排他に要するリソースが増え,長い処理時間が必要となります。

●SQLオブジェクト用バッファの考え方
HiRDB/パラレルサーバでは,一つのSQL文に対して複数のSQLオブジェクトを作成しています。次にバックエンドサーバとフロントエンドサーバでの,SQLオブジェクトの特長を示します。
  • バックエンドサーバの場合
    該当するバックエンドサーバ(フロータブルサーバを含みます)ごとに実行する形式として作成されています。このため,バックエンドサーバのSQLオブジェクト用バッファには,フロントエンドサーバでバッファリングしているSQLオブジェクトのうち,該当するバックエンドサーバのSQLオブジェクトだけがバッファリングされるため,必要なSQLオブジェクト用バッファはフロントエンドサーバよりも少なく済みます。
  • フロントエンドサーバの場合
    フロントエンドサーバでは,バックエンドサーバのすべてのSQLオブジェクトをSQLオブジェクト用バッファに格納しています。このため,コストベース最適化によって,選択できるアクセス手順にSQLオブジェクトが作成されるため,相当量のSQLオブジェクト用バッファがないと効果がありません。
    なお,ストアドプロシジャ及びストアドファンクションについても同様のことが言えます。ストアドプロシジャ及びストアドファンクションの場合,通常のSQLと比べて特にSQLオブジェクトサイズが大きくなるため注意してください。

なお,次に示す統計情報と合わせて解析すると効率良く性能を向上できます。

<この項の構成>
(1) チューニング方法(その1)
(2) 解析方法(その2)
(3) 解析方法(その3)
(4) 解析方法(その4)

(1) チューニング方法(その1)

参照する情報
統計解析ユティリティの「システムの稼働に関する統計情報」の次に示す情報を参照してください。

チューニング方法
  1. SQLオブジェクト用バッファヒット率が低く,バッファ中のSQLオブジェクト情報合計長が短い場合,ヒット率を高くできない業務形態と考えられます。
  2. SQLオブジェクト用バッファヒット率が低く,バッファ中のSQLオブジェクト情報合計長が長い場合,SQLオブジェクト用バッファが不足していると考えられます。
なお,SQLオブジェクト用バッファヒット率は次の計算式で求めてください。
SQLオブジェクト用バッファヒット率(%)=
(SQLオブジェクトバッファヒット回数÷SQLオブジェクト取得要求回数)×100

対策方法
SQLオブジェクト用バッファが不足している場合,pd_sql_object_cache_sizeオペランドの指定値を大きくしてください。

(2) 解析方法(その2)

参照する情報
統計解析ユティリティの「システムの稼働に関する統計情報」の次に示す情報を参照してください。

チューニング方法
SQLオブジェクトバッファから出されたSQLオブジェクトの数が小さくなるようにしてください。SQLオブジェクトバッファから出されたSQLオブジェクトの数が多くなるとSQLオブジェクトの再作成による処理時間が長くなり,SQLオブジェクト用バッファの使用状況が悪いと考えられます。

対策方法
pd_sql_object_cache_sizeオペランドの値を大きくしてください。

(3) 解析方法(その3)

参照する情報
統計解析ユティリティの「システムの稼働に関する統計情報」の次に示す情報を参照してください。

チューニング方法
SQLオブジェクト長(REQUEST SQLOBJ SIZE)とストアドプロシジャのオブジェクト長(REQUEST STRT SIZE)の合計の最大値が,指定したバッファ長よりも大きい場合,SQLオブジェクトを実行するためのメモリが確保できないと考えられます。

対策方法
pd_sql_object_cache_sizeオペランドの値を大きくしてください。

(4) 解析方法(その4)

参照する情報
統計解析ユティリティの「システムの稼働に関する統計情報」の次に示す情報を参照してください。

チューニング方法
通常,CALL文でストアドプロシジャを実行する場合,リコンパイルは発生しません。しかし,ストアドプロシジャ内で使用している表に対してインデクスを追加したり,使用していないインデクスを削除したりするとリコンパイルが発生します。このリコンパイルは,CALL文でストアドプロシジャを実行するごとに発生するため,性能劣化の原因となります。
リコンパイルが発生していたら,ストアドプロシジャ内で使用している表に対して上記の変更があったと考えられます。

対策方法
ALTER PROCEDURE又はALTER ROUTINEで,ストアドプロシジャを再作成してください。