適切なインデックスを使った検索を行っているにもかかわらず、処理に時間がかかっている例および対策を以下に示します。
表示例
Symfoware Server Performance Monitor / SQL detailed information
Start time: 2008/10/16 13:45:53.145
End time: 2008/10/16 13:45:59.627
Running time: 6.482
Connection ID: 2008101015375000000458
Connection information:
Uid: I4874
Pid: 12521
Sid: -----
Type: SQL
Name: APL001/CONNECT1
Client information:
Client: u=UserID,i=RequestID,h=HostName
Module: IJServer01
Action: -----
Termination status:
Status: normal
Message Number: 2001
SQL statement:
SELECT C2 FROM USR1.TBL1 WHERE C1=80
Access plan:
Convert SQL statement:
SELECT TBL1.C2 FROM USR1.TBL1 WHERE TBL1.C1=?
===============================================================================
Main query
=sno===sectname=====input1==============input2==============output/update======
1 : SCAN [TBL1IXDSO1 ][ ][SORT0001 ]
-------------------------------------------------------------------------------
[ 1] SCAN ELEMENT
table name USR1.TBL1
scan type INDEX KEY SCAN(1)
dso name TBL1IXDSO1 [REC/SH]
condition evaluation No
scan record number 1
[ 2] INSERT ELEMENT
table name SORT0001
insert record length 12
-------------------------------------------------------------------------------
2 : SCAN [SORT0001 ][TBL1DSO ][APPL ]
-------------------------------------------------------------------------------
[ 1] SCAN ELEMENT
table name SORT0001
scan type TABLE ALL SCAN
condition evaluation No
[ 2] SCAN ELEMENT
table name USR1.TBL1
scan type TABLE KEY SCAN
dso name TBL1DSO [REC/SH]
condition evaluation Yes
scan record number 1
[ 3] OUTPUT ELEMENT
record length 23
Execution environment
-------------------------------------------------------------------------------
transaction access mode : READ WRITE
transaction isolation level : REPEATABLE READ
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
SS_RATE : 0.200000 0.250000 0.500000 0.400000 0.000100
Sampling status:
ACTIVE: 1
WAITING: 5
LOCK: 5
対策
アクセスプランを見ると、アクセス方式は“INDEX KEY SCAN”となっており、適切にインデックスを使用した検索となっていることが確認できます。インデックスを検索したあとも、インデックスから取り出した情報をもとに“TABLE KEY SCAN”により正しく表へのアクセスが行われており、アクセスプラン自体には問題がないことがわかります。
遅くなっている原因を調べるために、サンプリングした実行状態の内訳を参照すると、処理中断の状態(WAITING)を5回検出しており、5回ともトランザクション占有待ち(LOCK)で待ちとなっていることがわかります。このことから、検索対象となっているレコードへのアクセスが、他のトランザクションのアクセスと競合したため、処理に時間がかかったことがわかります。rdbpmreportコマンドでこのSQL文が実行されていたときの資源の占有待ちに関する情報を確認することで、裏付けをとることができます。
対策として、以下が考えられます。
排他の単位が行になっていなければ行に変更する
トランザクションの独立性水準を変更する
排他の単位は、アクセスプラン情報の“R_LOCK”の項目で確認ができます。この例では“YES”となっているため、排他の単位は行になっており、問題ないことがわかります。
トランザクションの独立性水準は、アクセスプラン情報の“transaction isolation level”の項目でわかります。この例では“REPEATABLE READ”となっています。処理の論理上問題ないか否かを確認して、独立性水準を“READ UNCOMMITTED”に変更するということが対策として考えられます。