rdbpmsqllistコマンドを使用して、処理が長くなっているSQL文のアクセスプランと処理の内訳を表示した例および対策を以下に示します。
表示例
Symfoware Server Performance Monitor / SQL detailed information
Start time: 2008/10/16 11:21:03.332
End time: 2008/10/16 11:21:13.541
Running time: 10.209
Connection ID: 2008101015375000000458
Connection information:
Uid: I4874
Pid: 12521
Sid: -----
Type: SQL
Name: APL001/CONNECT1
Client information:
Client: -----
Module: -----
Action: -----
Termination status:
Status: normal
Message Number: 2001
SQL statement:
SELECT C1 FROM USR1.TBL1 WHERE C2=100
Access plan:
Convert SQL statement:
SELECT TBL1.C1 FROM USR1.TBL1 WHERE TBL1.C2=?
Advice to an SQL statement:
JYP2401I 表の全件検索を行います．
===============================================================================
Main query
=sno===sectname=====input1==============input2==============output/update======
1 : SCAN [TBL1DSO ][ ][APPL ]
-------------------------------------------------------------------------------
[ 1] SCAN ELEMENT
table name USR1.TBL1
scan type TABLE ALL SCAN
dso name TBL1DSO [NONE/NONE]
condition evaluation Yes
scan record number 1
[ 2] OUTPUT ELEMENT
record length 23
Execution environment
-------------------------------------------------------------------------------
transaction access mode : READ WRITE
transaction isolation level : READ UNCOMMITTED
R_LOCK : YES
JOIN_RULE : AUTO
JOIN_ORDER : INSIDE
SCAN_KEY_ARITHMETIC_RANGE : YES
SCAN_KEY_CAST : YES
TID_SORT : YES
TID_UNION : YES
USQL_LOCK : SH
IGNORE_INDEX : NO
INACTIVE_INDEX_SCAN : YES
SAME_COST_JOIN_ORDER : ORDER
GROUP_COL_COND_MOVE : YES
CHOOSE_TID_UNION : NO
MAX_SCAN_RANGE : 1000
SS_RATE : 0.200000 0.250000 0.500000 0.400000 0.000100
Sampling status:
ACTIVE: 3
WAITING: 10
DB_READ: 10
対策
アクセスプランの情報を見ると、表“USR1.TBL1”からデータをとってくるだけの単純な検索処理です。SCANエレメントのアクセス方式を見ると“TABLE ALL SCAN”となっており、表から全レコードを取り出す処理が動作していることがわかります。表から全レコードを取り出す処理は、その表の最初のデータから最後のデータまでをくまなく参照することになるため、表に格納されているデータの量に依存して処理時間が長くなります。そのため、データ量の多い表に対しては避けるべきアクセス方式となります。
確認のためにサンプリングした実行状態の内訳を参照すると、“DB_READ”が10回となっており、多くのタイミングでデータベースからのデータ読込み待ちが発生していることがわかります。このことから、データ量の多い表からすべてのデータを読み込んで参照しているため時間が長くかかっていることが確認できます。
このようにデータ量の多い表に対して避けるべきものとしては、他にNESTED LOOP JOINエレメントがあります。
この問題は、適切なインデックスを付けることで解決します。SQL文のWHERE句を見てみると“C2”カラムでの検索条件がついています。しかし、この表には“C2”カラムにはインデックスを付けていませんでした。“C2”カラムにインデックスを付ければ、表に対する全データの読出し処理ではなく、インデックスを用いた高速な検索処理が動作するようになるため、性能は大幅に改善されます。
SQL文に記述されている検索条件やジョインの条件を見て、適切なインデックスを付けることで、このような問題は解決することができます。