その他の原因によるチューニングについて説明します。
CASTオペランドにインデックス構成列を指定して、インデックスの範囲検索を行いたい場合があります。最適化パラメタ“SCAN_KEY_CAST”で、インデックス検索の適用を拡大することで、CASTオペランドについてもインデックスの範囲検索を行います。
以下の場合、チューニングの効果があります。
WHERE句または結合表の結合条件に、CASTに指定した列と、列を含まない値式を比較述語“=”で指定している場合。
インデックス定義
人事テーブル．IX1<従業員番号> 従業員番号：DEC(6)
SELECT 等級
FROM 人事テーブル
WHERE CAST(従業員番号 AS CHAR(8)) = '123456'
以下の場合、チューニングの効果があります。
WHERE句または結合表の結合条件に、表の列同士を比較演算子“=”で指定した条件(表の結合関係を表す条件)を指定している。かつ、
上記の条件の比較演算子“=”で指定した片方または両方の列をCASTオペランドに指定している場合。
インデックス定義
人事テーブル.IX1<従業員番号> 従業員番号：DEC(6)
目標管理テーブル.IX2<従業員番号> 従業員番号：INTEGER
SELECT 人事テーブル.従業員名,目標管理テーブル.難易度
FROM 人事テーブル,目標管理テーブル
WHERE 人事テーブル.従業員番号
= CAST(目標管理テーブル.従業員番号 AS DEC(6))
アクセスプランを取得すると、データベース資源に対する占有単位、占有モードを知ることができます。競合するアプリケーションの占有単位および占有モードを確認して、デッドロックの発生の可能性が高い場合には、トランザクション占有のチューニングを実施します。
カーソルを使用してデータベースの更新を行う場合、カーソルの更新可能性句にFOR UPDATEを指定すると、占有モードは非共用モードとなります。読み込み時から非共用モードでデータベース資源を占有するため、デッドロックが発生しにくくなります。
アクセスプランの占有単位が“DSI”となっている場合は、表の全件検索やインデックスの全件検索が選択されています。DSI全体を占有したくない場合は、検索に利用できるインデックスを定義して、データベースの読込み範囲を小さくします。
なお、占有単位に“REC”が表示されている場合は、行単位の排他を指定している場合です。このときのアクセスモデルが表の全件検索であると、占有のためにレコード件数に比例したメモリを使用するため、表の全件検索とならないようにデータベースをチューニングしなければなりません。
UPDATE文：探索やDELETE文：探索において、更新対象レコードを位置づける部分の表の占有モードは“共用モード”がデフォルトです。OLTP業務などでUPDATE文：探索やDELETE文：探索を利用するときは、USQL_LOCKに“EX”を指定すると、更新対象レコードを位置づけるときに“非共用モード”で占有するので、デッドロックを起こしにくくなります。
リザルトバッファは、SELECT文で獲得したデータをアプリケーション側で保持しておく領域です。このバッファは、カーソルならその単位で使われます。たとえば、アプリケーションがカーソルを入れ子で使う場合は、その数だけ作成する方が性能が向上します。カーソルが入れ子になっているが、リザルトバッファが1枚しか作成されていない場合は、外側のカーソルについてはリザルトバッファを使用しますが、入れ子内のカーソルはFETCH文ごとに返却データをPRIMEFLEX for HA Databaseから獲得することになります。
SELECT文で得られるデータ量が大量のときは、リザルトバッファを大きくすることによって、アプリケーションとPRIMEFLEX for HA Database間の通信回数の削減となり、FETCH性能が向上する可能性があります。
リザルトバッファは、クライアント用の動作環境ファイルのRESULT_BUFFERに個数とサイズを指定します。
クライアント用の動作環境ファイル(64キロバイトのバッファが2枚の場合)
RESULT_BUFFER=(2,64)
注意
リザルトバッファの大きさは、返却データ長や返却レコード件数に依存します。リザルトバッファを大きくするとFETCH性能は向上しますが、使用メモリ量を圧迫するため、性能が頭打ちになったり下がることもあります。このため、リザルトバッファのチューニングを行う場合は、運用テストを行ってからサイズを決定することを推奨します。
